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ABSTRACT 


Logistics  can  substantially  affect  the  directions  of  warfare  campaigns. 
The  types  of  war  materiel  and  their  flow  rates  to  field  units  directly  impact  the 
campaign  outcome.  Although  many  wargaming  and  combat  simulations  have 
been  developed,  few  models  implement  the  detailed  effects  of  logistics  flow. 
This  thesis  develops  a  theater  level  logistics  flow  model  for  a  Blue  force  using  a 
forward  logistics  base  that  is  advancing  upon  an  objective  in  Red  defended 
territory.  The  model  computes  confidence  intervals  for  Blue’s  short  tons  of 
various  classes  of  supply  available  throughout  the  campaign.  Logistics  activity 
is  generated  at  user  defined  rates  using  four  periodic  and  event  driven 
consumption  mechanisms:  movement,  combat,  interdiction,  and  interdiction 
repair.  The  model’s  primary  function  is  receipt,  staging,  onward  movement,  and 
integration  for  materiel  consumed  by  Blue.  The  model  is  implemented  in 
MODSIM,  an  object-oriented  simulation  language  providing  both  synchronous 
and  asynchronous  events,  as  well  as  a  rich  class  of  data  structures  necessary  to 
implement  the  model.  The  basic  model  is  replicated  to  desired  confidence  and 
tolerance,  with  statistics  collected  for  the  amounts  of  the  various  classes  of 
supply  available  for  the  supported  units.  The  model’s  output  includes 
confidence  intervals  for  the  desired  measures  of  effectiveness. 


THESIS  DISCLAIMER 


The  reader  is  cautioned  that  computer  programs  developed  in  this  research  may 
not  have  been  exercised  for  all  cases  of  interest.  While  every  effort  has  been 
made,  within  the  time  available,  to  ensure  that  the  programs  are  free  of 
computational  and  logical  errors,  they  cannot  be  considered  validated.  Any 
application  of  these  programs  without  additional  verification  is  at  the  risk  of  the 
user. 
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EXECUTIVE  SUMMARY 


Logistics  can  substantially  affect  the  course  of  a  military  campaign-  The 
types  of  war  materiel  and  their  flow  rates  to  field  units  directly  impact  the 
campaign  outcome.  At  the  same  time,  military  planners  have  fewer  tools 
available  to  them  to  investigate  the  effects  that  logistics  might  have  on  a 
developmental  plan  than  they  do  tools  to  help  them  shape  the  combat  aspects  of 
that  plan. 

Campaign  issues  are  often  evaluated  using  established  combat  models  like 
TACWAR,  RESA,  and  JTLS.  Combined  with  live  exercises  and  wargames,  they 
can  provide  significant  insights  to  faults  in  the  plan  and  to  the  comparative 
strengths  and  weaknesses  of  competing  courses  of  action.  Some  of  these 
combat  models  do  have  extensive  logistics  modules  that  track  materiel 
expenditure;  however,  they  have  difficulty  analyzing  future  logistics 
requirements. 

This  thesis  develops  a  logistics  flow  model  to  fill  this  gap  in  investigating 
the  future  effects  of  logistics  on  ground  maneuver  and  combat  arising  from  a 
general  lack  of  logistics  planning  aids  in  modem  combat  models.  The  proposed 
model  is  an  object-oriented  modular  approach  that  allows  it  to  grow  and 
develop  easily  to  meet  future  needs  and  refinements. 

The  basic  purpose  of  the  model  is  to  provide  confidence  intervals  for  the 
amounts  of  war  materiel  supported  units  might  have  as  the  campaign 
progresses.  Logistics  consumption  mechanisms  like  movement,  combat, 
interdiction,  and  interdiction  repair  spur  the  logistics  flow  from  a  forward 
logistics  base  to  the  supported  units.  The  progress  of  these  units  in  reaching 
their  objective  is  directly  related  to  their  logistics  sustainability.  Two  measures 
of  effectiveness,  days  of  supply  and  events  of  supply,  are  used  to  measure 
sustainability.  The  goal  of  these  confidence  intervals  and  measures  of 
effectiveness  is  to  give  military  planners  insight  into  the  logistics  feasibility  of 
various  courses  of  action  over  an  extended  period,  complementing  the  ability  of 
current  combat  models  that  report  the  current  logistics  situation. 

Demonstrations  showcase  different  functional  areas  of  the  model  and 
show  that  the  ground  campaign  suffers  when  the  logistics  lines  of 
communication  are  stressed. 
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I.  INTRODUCTION 


A.  SCENARIO 

A  US  ground  commander  is  tasked  to  develop  a  campaign  plan  in  the 
event  that  hostilities  start  in  his  theater.  His  particular  campaign  will  be  a  part 
of  the  larger  overall  war  plan;  fulfilling  this  particular  campaign  objective  is 
critical  to  the  overall  success  of  the  war. 

The  Korean  Peninsula  provides  such  a  case  in  point.  Should  hostilities  in 
the  Korean  theater,  in  a  state  of  armistice  since  July  1953,  resume,  then  plans  in 
current  development,  review,  and  implementation  will  be  put  into  action. 

B.  DISCUSSION 

The  commander  developing  a  campaign  has  many  combat  models 
available  for  investigating  various  courses  of  action.  Tactical  Warfare 
(TACWAR),  Research,  Evaluation,  Simulation,  and  Analysis  (RESA),  and  Joint 
Theater  Level  Simulation  (JTLS)  are  several  that  the  US  military  presendy  uses. 

Often,  campaign  issues  are  also  studied  by  combining  live  wargames  and 
exercises  with  combat  model  analyses  in  an  effort  to  get  more  of  the  “man  in  the 
loop”  viewpoint  and  to  exercise  the  plan  to  find  its  limits.  Ulchi-Focus  Lens 
(UFL)  is  an  annual  exercise  in  South  Korea  that  does  just  this.  As  a  result,  a 
plan  has  been  examined  from  many  aspects  of  military  perspective  by  the  time  it 
is  mature.  At  the  same  time,  logistics  planning  for  the  campaign  may  be  less 
well  developed  for  several  reasons: 

1.  Most  exercises  are  considerably  shorter  than  the  anticipated  war. 
Accordingly,  calculating  the  effects  of  logistics  on  the  campaign  over  the  long 
term  requires  more  simulation  and  imagination  than  watching  Marines  spill 
ashore  over  several  days. 

2.  Although  established  combat  modeling  systems,  like  TACWAR, 
RESA,  and  JTLS,  have  integrated  logistics  modules,  these  modules  are  an 
adjunct  to  the  combat  focus  of  the  system.  For  example,  JTLS  will  restrict  the 
player  from  launching  a  missile  raid  if  the  firing  units  do  not  have  any  missiles, 
or  in  fact,  from  performing  any  activity  for  which  there  are  not  enough  supplies. 
The  player  must  create  and  execute  a  (logistics)  resupply  plan  and  launch  the 
raid  later.  While  this  may  allow  military  planners  to  identify  potential  logistics 
shortfalls  and  bottlenecks,  it  requires  staffs  to  play  the  war  game  for  an 
extended  period  just  to  see  the  logistics  picture  for  one  course  of  action. 
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3.  The  accuracy  of  long  term  logistics  forecasting  degrades 
substantially  as  the  timeline  is  played  out.  Also,  logistics  usage  depends  heavily 
on  the  events  which  unfold  in  the  scenario.  Trying  to  integrate  any  forecast  to 
the  vagaries  of  war,  or  a  war  plan,  magnifies  the  complexity  of  accurate 
forecasts. 

Military  planners  have  few  tools  available  for  logistics  planning  due  to  the 
difficulties  involved.  At  the  same  time,  command  and  control  systems  like 
JOPES  (Joint  Operational  Planning  and  Execution  System)  and  WMCCS  (World 
Wide  Military  Command  and  Control  System)  use  logistics  patterns  as  an 
integral  part  of  an  operations  plan.  For  instance,  the  Time  Phased  Force 
Deployment  Data  (TPFDD)  schedules  unit  and  materiel  flow  into  the  theater  as 
the  war  unfolds.  Ideally,  effective  staff  work  moves  units  and  materiel  at 
compatible  rates  so  that  situations  in  which  several  divisions  are  available  to 
fight,  but  have  no  ammunition,  or  depots  are  full  of  ammunition  and  have  no 
customers,  develop.  Military  staffs  entering  the  TPFDD  may  have  to  resort  to 
best  guesses  about  how  much  materiel  to  flow  and  when  to  move  it  without 
either  good  data  or  good  modeling  tools. 

In  spite  of  these  planning  difficulties,  the  needs  of  logistics  in  conflict  do 
not  wait  for  planning,  as  the  US  experience  in  Operations  Desert  Shield/Desert 
Storm  (DS/DS)  demonstrated.  General  Pagonis,  the  commanding  general  for 
logistics  in  DS/DS,  wrote  of  his  experience  in  August,  1990  of  watching  nearly 
every  logistician  in  the  theater  try  to  process  plane  load  after  plane  load  of  the 
arriving  82nd  Airborne  [Ref  1:  p.  85].  He  summarized  the  vast  quantities  of 
materiel  that  the  US  used  and  moved,  writing: 

...In  the  year  between  August  1990  and  August  1991...the 
logisticians... planned,  moved,  and  served  more  than  122  million 
meals.  This  can  be  compared  to  feeding  all  of  the  residents  of 
Wyoming  and  Vermont  three  meals  a  day  for  forty  days. 

...Between  August  1990  and  August  1991,  those  same 
supply  units  pumped  1.3  billion  gallons  of  fuel...roughly  equal  to 
the  12-month  fuel  consumption  of  the  District  of  Columbia, 
Montana,  and  North  Dakota  combined. 

...those  supply  units  and  their  contracted  drivers  drove 
almost  52  million  miles  in  the  war  theater.  This  is  the  equivalent 
of  more  than  100  round- trips  to  the  moon.  [Ref  1:  p.  1] 
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Another  aspect  of  DS/DS  that  worked  well  for  US  forces  was  the 
establishment  of  Forward  Logistics  Bases  (FLB) .  It  is  likely,  then,  that  having 
worked  well  in  DS/DS,  they  will  be  used  again  in  the  future. 

The  FLB  can  be  a  tent  city  erected  in  the  desert,  a  city  near  the  front,  or 
existing  infrastructures  improved  to  meet  the  needs  of  the  conflict.  Key 
characteristics  are  proximity  to  intermodal  infrastructures  such  as  seaports, 
airfields,  railheads,  and  highways.  Other  useful  intermodal  infrastructures 
include  canals,  rivers,  and  beaches  suitable  for  operations  like  Joint  Logistics 
Over  the  Shore  (JLOTS).  The  FLB  and  the  intermodal  infrastructures  between 
the  bases  and  the  troops  must  also  be  able  to  support  the  troop’s  style  of 
warfare.  Forces  advancing  rapidly,  hoping  to  maneuver  past  opposition  before 
reaching  the  objective,  might  experience  rapidly  elongating  lines  of 
communication  susceptible  to  interdiction. 

C.  COMPLEMENTING  COMBAT  MODELS 

The  flow  of  logistics  can  either  help  or  hinder  a  campaign,  and  therefore 
the  war.  The  campaign  plan,  then,  needs  effective  logistics  planning.  A 
campaign  is  developed  through  the  process  of  comparing  different  courses  of 
action.  The  differing  feasibilites  of  these  courses  distinguish  stronger  plans 
from  weaker  ones,  as  well  as  giving  insights  to  the  multitude  of  ways  the  plan 
might  disintegrate  when  it  comes  in  contact  with  the  enemy  for  the  first  time. 
Ideally,  logistics  planning  is  an  integral  part  of  development,  rather  than  a 
follow-on  process  to  the  campaign  planning,  for  the  same  reasons. 

A  useful  tool  to  integrated  development  would  be  a  model  that 
anticipates  future  logistics  requirements  so  that  planners  can  create  more 
proactive  logistics  plans.  Such  a  model  would  become  a  step  beyond  using  the 
logistics  modules  contained  in  current  combat  models,  where  the  model 
facilitates  planning  with  comparative  courses  of  action  analyzed  from  a  logistics 
perspective.  The  model  would  show  insights  to  important  questions,  such  as 
how  much  materiel  might  the  supported  units  have  well  into  the  campaign,  and 
whether  or  not  the  logistics  flow  help  or  hurt  the  advance. 

This  thesis  proposes  such  a  model.  The  proposed  model  bases  logistics 
flow  from  a  FLB  at  the  theater  entrance  and  uses  logistics  planning  factors  tied 
to  friendly  Blue  and  unfriendly  Red  activity  to  simulate  die  campaign  from  a 
logistics  point  of  view.  The  resulting  model  complements  and  extends  the  focus 
of  current  combat  modeling  efforts. 
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II.  METHODOLOGY 


This  chapter  develops  the  framework  for  the  model.  The  following 
chapters  describe  the  logistics  flow  model  and  how  the  model  is  executed  in 
MODSIM  II. 

A.  THE  PURPOSE  OF  THE  MODEL 

This  thesis  offers  a  logistics  flow  model  that  simulates  the  effects  of 
logistics  on  ground  combat  and  maneuver  with  the  goal  of  giving  military 
planners  indicators  for  the  levels  of  logistics  support  a  FLB  can  give  and  for  the 
effects  of  the  intermodal  infrastructures  on  that  flow.  These  indicators  are 
measured  by  how  much  materiel  Blue  has  at  the  front  throughout  the  campaign. 

B.  MODEL  METHODOLOGY 

The  model  is  network  flow  based;  nodes,  demands,  and  arcs  represent 
elements  of  infrastructure  and  lines  of  communication  (LOC).  Materiel  moves 
from  the  FLB  to  the  front  using  this  network  each  time  the  model  is  used  for  a 
given  scenario.  Each  scenario  is  defined  by  a  set  of  user  inputs. 

User  inputs  to  the  model  are  databases  detailing  the  forces,  including 
their  logistics  and  weapons  loadouts,  cartography,  combat  modeling  factors  like 
attrition  rates  and  force  allocations,  and  a  depot  based  supply  system.  Logistics 
enter  the  theater  through  the  FLB.  Probabilistic  elements  are  used  to  create 
meaningful  differences  between  successive  runs  of  a  single  course  of  action. 
Running  a  series  of  scenarios  through  the  model  builds  the  different  courses  of 
actions  for  comparative  analysis  yielding  insights  to  the  logistics  portion  of  the 
campaign  plan. 

Each  time  the  model  is  run  for  the  simulation,  series  of  instantaneous 
looks  at  stock  levels  are  taken.  These  snapshots  from  a  single  run  portray  the 
logistics  flow  in  the  campaign.  The  corresponding  snapshots  from  a  series  of 
runs  show  a  range  of  possible  outcomes.  These  snapshots  are  like  a  series  of 
weather  observations:  if  viewed  from  January  to  December,  they  show  the 
march  of  the  seasons;  however,  if  several  year’s  worth  of  observations  for 
November  are  examined,  they  show  that  month  is  rainy  between  15  and  25  days 
95  percent  of  the  time.  Confidence  intervals  in  the  model  are  not  ones  of  rainy 
days,  but  of  a  range  in  short  tons  of  the  materiel  stockpiled  by  particular  unit  at 
a  particular  time. 

It  is  important  to  note  that  the  simulations  provide  planners  with 
comparative  analysis  instead  of  predictive  analysis.  The  simulations  cannot 
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determine  how  much  materiel  will  arrive  at  a  position,  given  the  level  of  combat 
and  interdiction.  Rather,  they  give  planners  an  estimate  of  the  logistical  support 
possible  over  a  range  of  likely  scenarios.  Planners  must  then  decide  whether  the 
desired  combat  momentum  is  maintainable. 

C.  ASSUMPTIONS 

The  following  assumptions  provide  the  framework  within  which  the 
model  operates. 

1.  Hostilities  may  occur  with  little  to  no  notice.  Blue  might  not  have 
time  to  preposition  materiel  in  theater. 

2.  Blue  effects  timely  closure  in  the  Tactical  Assembly  Areas.  This 
starts  Blue  with  a  full  complement  of  logistics  users. 

3.  Chemical,  Biological,  and  Radiological  (CBR)  agents  are  not  used. 
The  scope  of  logistically  supporting  a  war  in  a  CBR  environment  is  beyond  the 
scope  of  this  analysis. 

4.  Logistics  support  is  a  discrete  process.  Materiel  arrives  in 
individual  vehicles  in  specific  amounts  at  specific  times. 

5.  The  FLB  has  an  airfield,  a  seaport,  railheads,  highways  and  nearby 
beaches  suitable  for  JLOTS  operations. 

D.  MEASURES  OF  EFFECTIVENESS 

Days  of  Supply  and  Events  of  Supply  are  the  two  indicators  of 
sustainability  used  as  measures  of  effectiveness.  The  measure  used  for  a 
particular  commodity  depends  upon  the  rates  and  conditions  of  its  use. 

1.  Days  of  Supply  (DOS) 

DOS  is  the  ratio  of  the  remaining  material  on  hand  after  consumption 
each  day  to  the  material  used  each  day.  This  number  is  an  indicator  of  how 
many  more  days  the  unit  will  have  that  material.  DOS  is  the  MOE  for  items 
consumed  in  a  regular  predictable  fashion.  Items  like  water  and  food  rations  are 
well  suited  to  measure  with  DOS  since  their  usage  rate  can  be  meaningfully 
expressed  as  a  function  of  time.  Equation  2. 1  defines  days  of  supply: 
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r\y^\o  _  Onhandj 

UVZi  -  Usage. 


Vi  (2.1) 


where  Onhandi  is  the  STONS  of  supply  dass  i  available.  Usage{  is  the  STONS  of 
supply  dass  i  used  each  day.  Usage,  is  determined  from  logistics  planning 
factors  appropriate  to  the  level  of  combat  activity.  The  classes  of  supply  are 
discussed  in  Chapter  III,  Section  F.  Shortfalls  in  supply  occur  when  DOS  falls 
below  an  acceptable  level  determined  by  military  planners. 

2.  Events  of  Supply  (EOS) 

Blue  forces  consume  other  commodities  at  rates  that  cannot  be 
reasonably  predicted  as  a  function  of  time.  Items  such  as  ammunition  are  used 
conditionally.  Ammunition  is  used  in  combat  at  a  rate  determined  by  the  pace 
of  combat.  EOS  is  the  ratio  of  the  remaining  materiel  onhand  after 
consumption  to  the  materiel  used  in  each  event  of  usage.  Equation  2.2 
expresses  this  relationship. 


EOSi  = 


Onhandi 

jrlUsedy 


Vi  (2.2) 


Usedij  is  the  amount  of  supply  dass  i  materiel  used  in  the  Ith  of  N  total  events 
expending  that  materiel.  EOS  is  an  indicator  of  how  many  more  events  the  unit 
can  undertake  before  running  out  of  that  materiel.  Like  DOS,  shortfalls  in  EOS 
develop  when  the  unit  cannot  meets  the  demands  for  an  expected  number  of 
actions  without  resupply. 
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III.  THE  LOGISTICS  FLOW  MODEL 


A.  PURPOSE 

The  model  supports  the  purpose  of  the  analysis  by  generating  a  series  of 
logistics  flow  snapshots  in  the  theater.  These  snapshots  show  the  logistics 
receipt,  staging,  onward  movement,  and  integration  (RSO&I)  flow  as  the 
campaign  progresses.  After  the  model  is  replicated  many  times,  all  of  the 
corresponding  snapshots  from  each  run  are  combined  to  form  the  confidence 
intervals. 

The  primary  function  of  the  model  is  to  generate  logistics  flow  into  the 
theater  and  forward  logistics  base,  and  onward  to  the  supported  units.  The 
logistics  flow  is  generated  with  four  consumption  mechanisms  that  interact  to 
consume  materiel  and  create  logistics  needs.  These  mechanisms  are  Blue 
movement.  Blue  combat  with  Red,  Red  interdiction  of  fines  of  communication 
and  intermodal  infrastructures,  and  Blue  interdiction  repair  processes. 

B.  MODEL  CONCEPT 

Conceptually,  the  model  portrays  theater  logistics  flow  supporting  one  of 
two  forces  in  conflict.  The  supported  Blue  forces  are  advancing  upon  an 
objective  held  by  the  Red  forces.  Red  attempts  to  stop  Blue  with  direct  combat 
and  interdiction  efforts.  Logistics  materiel  flows  into  the  theater  all  the  while. 
Both  Blue  and  RSO&I  depend  upon  the  conditions  of  the  various  intermodal 
infrastructures:  impassable  roads,  dropped  bridges,  and  blown  tunnels  delay 
obtaining  the  objective  or  supporting  the  combat  force.  The  infrastructures 
might  be  damaged  by  limited  Blue  strikes,  by  Red  scorched  earth  tactics  before 
they  are  captured,  or  through  Red  interdiction  afterwards. 

The  model  is  a  multi-commodity,  multi-depot,  transport  mode 
time-phased  network.  Network  constraints  include  road  and  seaport 
throughput.  Red  interdiction  efforts,  and  Blue’s  rate  of  advance.  The 
mathematical  description  of  the  logistics  flow  and  attacker  advance  provides  a 
feasible  region  for  the  simulation  to  play  to  various  ends. 

From  a  design  point  of  view,  the  model  must  be  both  abstract  enough  for 
manageable  implementation  and  analysis,  yet  sufficiently  concrete  to  retain 
enough  fidelity  to  capture  the  essence  of  the  real  world  events  it  mimics.  Figure 
3.1  illustrates  the  basic  data  structure  of  the  model. 

To  provide  logistics  snapshots,  the  model  has  to  consider  several  factors 
affecting  materiel  throughput:  LOC's,  the  pace  of  combat,  intermodal 
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infrastructure  conditions,  and  the  availability  of  certain  classes  of  supply.  The 
model  captures  materiel  RSO&I  and  consumption,  allowing  Blue  to  advance 
upon  the  objective  in  a  reasonably  lifelike  fashion. 


Consumption  is  a  function  of  both  materiel  usage,  as  through  movement, 
and  destruction,  as  through  interdiction.  Materiel  usage  rates  vary  with  the 
aggressor’s  activities.  Some  rates,  like  subsistence  materiel,  are  fairly  constant 
despite  activity;  while  others,  like  ammunition  and  POL,  will  vary  greatly. 

Since  the  goal  of  the  analysis  is  to  determine  what  levels  of  logistical 
support  the  campaign  might  have,  the  simulation  cannot  occur  in  a  logistics 
vacuum.  Some  interaction  between  supplies  on  hand  and  activity  must  occur. 
For  instance,  it  would  be  impossible  for  Blue  to  advance  if  there  is  no  fuel, 
ammunition,  or  subsistence  on  hand. 
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c. 


DATA  STRUCTURE 


The  data  structure  organizes  information  into  a  format  which  supports 
the  model  and  ensures  that  the  necessary  data  are  available  to  the  functions  that 
must  manipulate  them.  Three  broad  areas  are  supported,  as  shown  in  Figure 
3.2:  a  network,  a  logistics  delivery  system,  and  a  force  structure  system.  (See 
Appendix  A  for  a  description  of  the  model  mapping  form.) 


Figure  3.2.  Basic  object-oriented  model  data  structure.  The  model  uses  a  map  upon 
which  Blue  and  Red  forces  move.  A  depot  system  composed  of  a  forward  logistics  base 
and  intermediate  depots  supplies  Blue. 


1.  The  Network 

All  the  processes  of  Figure  3.1  rely  upon  a  geographical  representation  of 
a  map  as  a  network.  Intermodal  infrastructures  such  as  rail  heads,  air  ports,  sea 
terminals,  highway  junctions,  and  tunnels  are  represented  on  the  map.  Nearby 
intermodal  infrastructures  are  bundled  together  as  network  nodes,  as  shown  in 
Figure  3.3.  Materiel  may  move  freely  between  these  collocated  infrastructures: 
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materiel  may  be  directly  moved  from  the  sea  port  to  the  rail  station  if  they  are  in 
the  same  geographic  location.  All  nodes  with  air  intermodal  infrastructures  are 
connected,  as  are  those  with  sea  infrastructures.  The  relationship  between 
Figures  3.2  and  3.3  is  the  network  representation  of  the  map.  The  sites  in  the 
data  structure  are  the  collections  of  the  various  intermodal  infrastructures,  or 
terminals.  Terminals  are  connected  to  other  terminals  at  other  sites  with  arcs. 


Figure  3.3.  Network  concept  diagram.  Collocated  intermodal  infrastructures 
form  nodes,  representing  geographic  locations. 


Arcs  connecting  the  nodes  represent  a  transportation  mode  between  two 
geographic  locations  and  exist  at  specific  times.  The  arcs  represent  Blue’s  lines 
of  communication;  as  Blue  advances  or  withdraws,  these  lines  grow  and  shrink. 
Therefore  the  network  is  dynamic;  its  size  depends  upon  Blue’s  advance.  As 
Blue  advances,  LOC's  are  established  and  are  subject  to  interdiction  by  Red.  If 
interdicted,  then  the  arc  is  disestablished  until  Blue’s  engineering  assets  have 
repaired  the  damage. 

2.  Logistics  Delivery  System 

The  data  structure  creates  elements  storing  the  data  of  the  logistics 
system  described  in  greater  detail  in  Section  F. 
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3.  MovingObj 

The  model  defines  an  entity  MovingObj  that  is  able  to  move  on  the 
network.  A  MovingObj  contains  any  data  needed  to  move,  such  as  movement 
speeds  for  various  terrain  types.  Two  children  entities  of  MovingObj  are  also 
used:  a  TransportObj  and  a  UnitType.  These  descendants  store  the  additional 
information  necessary  to  further  define  a  MovingObj  into  many  entities  with 
special  characteristics.  All  structures  representing  organizational  military  units 
are  fashioned  with  UnitTypes.  A  UnitType  uses  other  data  structures  that 
enumerate  weapons  configurations  and  capabilities.  TransportObjs  are  the 
building  blocks  for  all  forms  of  transportation  used  to  move  supplies  on  the 
network. 

D.  PROBABILISTIC  ELEMENTS 

Uncertainty  is  an  important  aspect  of  the  model,  as  it  is  in  warfare. 
Uncertainty  enters  the  model  in  several  areas: 

1.  Travel  delays.  Units  experience  delays  as  they  pass  through  sites. 
These  delays  are  modeled  with  a  truncated  normal  distribution. 

2.  Usage.  The  amounts  of  materiel  consumed  are  calculated  from 
logistics  planning  factors.  Once  they  have  been  calculated,  they  are  adjusted  by 
an  error  factor  having  a  normal  distribution  whose  standard  deviation  is 
arbitrarily  set  as  3-5  percent  of  the  calculated  amount.  The  magnitude  of  the 
error  factor  may  be  adjusted  as  desired. 

3.  Theater  receipt.  Materiel  flowing  into  the  theater  due  to  shortfalls 
experience  a  delay  whose  distribution  is  a  truncated  normal.  This  wait  time  is 
imposed  to  simulate  those  delays  materiel  shipped  to  the  theater  might 
experience  enroute  in  real  world  operations  due  to  such  as  factors  as  Stateside 
backorder,  intermediate  travel  delays,  misrouting,  etc. 

E.  TIME 

Material  consumption  occurring  on  a  predictable  basis  is  computed  daily. 
Other  consumption  events  are  scheduled  to  occur  whenever  their  condition  are 
met.  For  instance,  the  troops  feed  once  every  twenty  four  hour  cycle,  but  fight 
and  consume  ammunition  only  when  they  are  in  contact  with  the  enemy.  Data 
collection  for  the  analysis  occurs  every  twenty  four  hours  after  all  daily 
occurring  events  have  occurred. 
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F.  FUNCTIONAL  AREAS 


The  model  operates  by  using  its  various  processes  to  manipulate  the 
input  databases  to  gain  useful  information  and  insights.  The  primary  function  of 
die  model  is  RSO&I.  Four  mechanisms  use  supplies:  movement,  combat, 
interdiction,  and  repair.  Other  functional  areas  which  do  not  consume  supplies 
include  network  management  and  data  collection. 

1.  Receipt,  Staging,  Onward  Movement,  and  Integration 
(RSO&I) 

In  the  model.  Blue  uses  and  replenishes  supplies.  A  forward  logistics 
base  serves  as  the  root  to  Blue’s  theater  logistics  tail.  Intermediate  depots  may 
support  Blue  along  the  way  to  the  objective. 

Aggregating  the  Classes  of  Supply 

Table  3.1  shows  how  the  general  classes  of  supply  are  aggregated 
into  three  categories  determined  by  their  combat  utility.  Primary  categories  are 
essential  to  the  effectiveness  of  the  unit  and  are  tracked  by  themselves. 
Secondary  categories  are  necessary  to  the  unit,  but  can  be  tracked  as  an 
aggregated  group.  Tertiary  categories  are  nonessential  and  are  discarded. 


Supply  Class 

Aggregated  Class 

Category 

Description 

I 

I 

Primary 

Subsistence 

II 

II 

Secondary 

Clothing,  etc. 

III 

III 

Primary 

POL 

IV 

II 

Secondary 

Construction 

V 

V 

Primary 

Ammunition 

VI 

Discard 

Tertiary 

Personal 

VII 

VII 

Primary 

Major  End  Items 

VIII 

II 

Secondary 

Medical 

XI 

Discard 

Tertiary 

Repair 

X 

Discard 

Tertiary 

Nonmilitary 

Table  3.1.  Aggregated  supply  class  list.  The  five  aggregated  classes  used  in  the 
model  are  (I)  subsistence,  (II)  super,  (III)  POL,  (V)  ammunition,  and  (VII) 
major.  Supply  classes  II,  IV,  and  VIII  are  the  classes  contained  in  the  aggregated 
super  class.  With  the  exception  of  aggregated  class  II  (super),  the  aggregated 
class  number  is  the  same  as  the  supply  class  number. 
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b.  Logistics  Flow 


The  logistics  flow  is  a  pull  system  in  which  the  supported  units  use 
supplies  and  replace  them  by  using  generated  requests  to  cause  a  delivery 
system  to  transport  replacement  materiel.  Each  time  materiel  is  consumed,  the 
unit  checks  that  commodity’s  amount  on  hand  against  that  commodity’s 
capacity,  reorder  percent,  and  amount  already  on  order.  When  the  amounts  on 
hand  fall  below  the  reorder  point,  adjusted  for  amounts  already  on  order,  then 
requisitions  are  generated.  Each  requisition  is  assigned  a  priority.  The  initial 
priority  sets  to  a  default  for  the  unit  type  making  the  request.  The  higher  the 
priority  number,  the  higher  the  priority  of  the  requisition. 

The  requisition  enters  the  depot  system  and  is  sent  either  to  the 
closest  intermediate  depot,  if  there  is  one,  or  to  the  forward  logistics  base,  if  no 
other  depot  is  available.  The  depot  fills  what  it  can  and  backorders  the  rest  from 
the  next  depot  or  from  the  forward  logistics  base.  The  priority  of  the 
backordered  amount  is  increased.  Materiel  is  pulled  into  the  theater  anytime  a 
requisition  order  or  backorder  from  the  forward  logistics  base  cannot  be  filled. 

Requisitions  are  filled  by  the  depot  according  to  priority  and  stock 
levels.  When  a  depot  has  an  order  ready  to  ship,  either  full  or  partial,  the  filled 
requisition  enters  the  depot  transportation  assignment  priority  queue. 
Transportation  assets  are  allocated  to  the  requisition.  Shortfalls  in 
transportation  cause  the  depot  to  generate  a  transportation  asset  request  for  the 
shortfall  amount.  Requisitions  then  wait  in  the  queue  until  transportation  is 
made  available,  either  through  new  assets  or  current  assets  returning  from 
deliveries.  A  convoy  is  formed  when  the  transportation  arrives  and  enters  the 
network  as  it  moves  towards  its  supported  unit  customer. 

2.  Movement 

Blue  and  Red  movement  allows  Blue  to  advance  on  the  objective  while 
creating  logistics  demands  that  consume  supplies.  Movement  on  the  map  is 
constrained  by  the  network.  Blue  and  Red  units  either  advance  or  withdraw.  A 
Red  unit  moves  until  a  Blue  unit  is  detected,  destroyed  infrastructure  blocks  the 
way,  or  the  FLB  is  overrun. 

Blue  will  move  as  long  as  subsistence,  POL,  and  ammunition  are  on  hand, 
and  no  contact  with  a  Red  unit  has  been  made.  As  soon  as  one  of  these  four 
conditions  changes,  the  Blue  unit  stops  until  the  situation  is  resolved.  If  the 
Blue  unit  has  used  all  of  its  POL,  it  must  stop  until  it  receives  fuel.  Any  of  the 
three  remaining  conditions  might  change  during  the  wait;  for  example,  if  a  Red 
unit  comes  close  enough  that  they  detect  each  other  while  Blue  awaits  fuel,  then 
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they  will  fight.  Should  Blue  win,  the  unit  must  continue  to  wait  until  it  receives 
POL  before  it  may  advance. 

In  the  case  of  a  withdraw  following  a  fight,  the  retreating  unit  stops  at  the 

first  site  after  contact  is  lost,  where  it  waits  a  period  of  time  as  described  in 
Section  D. 

3.  Combat 

Combat  between  Blue  and  Red  consumes  materiel  and  helps  determine 
when  Blue  moves.  Once  started,  combat  continues  until  one  side  reaches  its 
breakpoint  or  Blue  runs  out  of  ammunition.  Since  logistics  are  not  tracked  for 
Red,  Red  has  infinite  supplies.  The  breakpoints  used  for  Red  are,  therefore,  set 
high  so  that  Blue  is  not  unduly  penalized. 

The  duration  of  the  fight  is  the  time  needed  for  Red  or  Blue  to  reach  their 
breakpoint,  or  for  Blue  to  run  out  of  ammunition.  Since  the  combat  model  is  a 
linear  Lanchester  model,  the  duration  may  be  calculated  at  the  outset  of  the 

fight.  The  combat  model  contains  two  sub  modules;  a  detection  model  and  an 
attrition  model. 


a.  Detection  Model 

As  previously  discussed,  the  model  creates  a  class  of  entities  that 
can  move  called  MovingObj’s,  as  shown  in  Figure  3.2.  These  MovingObj’s 
moving  across  the  network  must  be  able  to  determine  whether  their  closest 
point  of  approach  lies  within  detection  range  of  another  MovingObj.  Combat 
occurs  whenever  a  Blue  and  Red  unit  lie  within  the  maximum  of  the  two 
detection  ranges.  Whenever  a  TransportObj,  shown  in  Figure  3.2,  carrying 
supplies  to  its  Blue  unit  customer  is  “detected”,  its  shipment  is  delivered.  This 
section  develops  the  algorithm  used  for  detection. 


Figure  3.4  shows  the  kinematics  for  two  objects,  Oi  and  02.  In  the 
model,  objects  move  on  the  map  from  point  to  point  on  a  line.  Changes  in 
direction  happen  when  the  object  arrives  at  a  node  on  the  map  and  leaves  it  for 
another  node  in  a  different  direction.  Since  speed  along  the  route  remains 
constant,  the  only  times  Vi  or  v2  may  change  are  whenever  Oi  or  02  arrive  and 
depart  an  intermediate  node. 

The  distance  between  Oi  and  02,  j  7^i2(/)j ,  is  a  function  of  time.  A 
detection  occurs  whenever  |~rn(o|is  less  than  the  greater  of  di  and  d2.  Of 
course,  the  detection  must  also  occur  before  either  object  arrives  at  an 
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intermediate  node  and  changes  its  velocity.  The  positions  of  Oi  and  02  are 
expressed  as  functions  of  time  in  Equations  3.1  and  3.2. 


r  i(0  =  [xi  +  vXlr]  i  +  [yi  +  vyit]j  (3.1) 

.  y  _ ^ 

r2(t)  =  [x2  +  vX2t]i  +\yi  +  vyit]j  (3.2) 


where  (x;,  y,)  is  the  initial  position  of  O;,  and  v  =  vxi  i  +Vyij  is  the 
initial  velocity  of  0,.  The  vector  component  directions  ?and  denote  the  x  and 
y  axes,  respectively. 


Figure  3.4.  Kinematics  of  Oi  and  02.  The  detection  ranges  are  di  and  d2.  The 
position  vectors  ri(t)  and  r2(t)  show  the  initial  positions,  while  r12(t)  is  the  position 
between  the  two  objects.  Vi  and  v2  are  the  velocities  of  Oi  and  02. 

The  position  vector  describing  the  position  of  02  with  respect  to 

Oi  is  the  difference  between  the  two  position  vectors.  Equation  3.5  defines  9(t) 
as  the  distance  between  Oi  and  02  at  time  t. 

~rn(t)  =  ~r2(t)-~ri(t) 

~r  i2(0  =  0(0  +  A  vxt]t  +  [(AXO  +  AV)]  j 


where  Ax  e  x2 (t)  - x \ (t)  and  Ay  =y2(t)-y\(t). 
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(3.3) 

(3.4) 

(3.5) 


If  Oi  and  02  are  dosing,  then  d(t)  decreases  as  t  approaches  the  time  of  the 
dosest  point  of  approach.  Let  t'  be  a  time  between  t  and  the  time  of  the  dosest 
point  of  approach.  If  Oi  and  02  are  dosing,  then  Equation  3.6  is  true. 
Furthermore,  Equation  3.7  defines  an  upper  bound  for  the  value  of  t'  since  the 
right  hand  side  is  the  soonest  time  Oi  and  02  can  possibly  intercept  each  other. 

Bit)  >  6{t')  (3.6) 


^  m 

(0 

— ^ 

V  1 

+ 

» 

;  2 

(3.7) 


A  special  case  of  Equation  3.6  occurs  when  the  closure  rate  is  zero,  but  Oi  and 
02  already  lie  within  dj,  d2 ,  or  both.  If  Oi  and  02  are  closing,  then  the  closure 
time  is  determined  by  setting  the  distance  between  the  objects  equal  to  the 
maximum  detect  radius  and  solving  for  t: 

^  =  mdx(d\,d2) 

(3.8) 

€  =  Bit) 

(3.9) 

£2  =  (Ax  +  A  vxt)2  +  (Ay  +  Avyt)2 

(3.10) 

0  =  (Av2  +  Av2)?2  +  2(AxAv^  +  AyAvy)t  +  (Ax2  +  Ay 2  -  £2) 

(3.11) 

The  time  of  detection,  t,  is  the  minimum  of  the  non-negetive  quadratic  roots  in 
Equation  3.11.  The  special  case  of  Equation  3.6  occurs  if  t=0.  If  t  occurs  before 
either  Oi  or  02  arrives  at  their  respective  destination,  then  a  detection  occurs. 


b.  Lanchester  Attrition  Model 

The  model  uses  a  heterogeneous  force  Lanchester  model  with 
modified  Bonder-Clark  methodology  for  estimating  the  casualty  rates  [Ref  2]. 
Here,  Blue  is  composed  of  i  =  l..m  weapon  types  or  systems,  and  Red  has  j  =  l..n 
systems.  These  systems  are  user  defined.  Fire  allocation  factors  are  also  set  by 
the  user  and  proportion  the  amount  of  one  weapon  type  firing  against  an 
opposing  weapon  type.  For  Red,  y/y  is  the  fraction  of  Rj  fires  allocated  to  B; 
targets.  The  fraction  of  Blue  fires  B-,  allocated  to  Red  targets  Rj  is  given  as  fo. 
The  further  conditions  that 

lr,  =  i  v2  (3.i2) 

I  (!,,  =  1  V  i  (3.13) 

are  necessary  to  assure  that  all  forces  are  accounted  for. 
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The  general  form  of  the  Lanchester  equation  used  in  the  model  is 
the  square  law  modified  for  heterogeneous  forces.  The  distinction  between  the 
square  (aimed  fire)  law  and  linear  (area  fire)  law  is  made  in  the  calculation  of 
the  casualty  rates.  Equation  3.14  shows  the  rate  at  which  Blue  type  i  system  is 
attrited  by  all  of  the  Red  forces.  Equation  3.15  shows  the  same  for  Red. 

=  -ZA,jRj  Viel.jw  (3.14) 

dR, 

=  -  2  CjiBi  Vy  g  \..n  (3.15) 


The  casualty  rates  Ay  and  Cy;  are  derived  using  conservative  estimators.  To 
develop  the  casualty  rates  Ay  and  Cy,-  for  aimed  fire,  o,y  is  defined  as  the  rate  at 
which  one  Red  weapon  type  j  attrites  one  Blue  weapon  type  z.  cfi  is  similarly 
defined  for  Blue  against  Red  The  values  for  Oy  and  ty  are  functions  of  the 
weapon  type’s  firing  rate  v  and  its  single  shot  kill  probability  P  for  the  target 
type.  For  Red  and  Blue,  these  become 

av  ~  vjPif  VJ,i  (3-16) 

. Cji  =  VjPji  V  i,j  (3.17) 


Since  the  forces  are  heterogeneous.  A,  and  Q  depend  not  only  upon  the  values 
in  Equations  3.16  and  3.17,  but  the  fire  allocation  factors  y/  and  /f  as  well. 
Equations  3.18  and  3.19  develop  A,  and  Cj,  for  aimed  fire  as  functions  of  the 
weapon  type’s  firing  rate,  its  single  shot  kill  probability  against  the  target  type, 
and  the  fraction  of  effort  of  the  weapon  type  against  the  target  type. 

Aij  =  V'i/O.j  =  VijVjP'j  Vj.i  (3.18) 

ViJ  (3.19) 

In  the  case  of  area  fire.  Equations  3.16  and  3.17  are  modified  to  account  for  the 
area  covered  by  the  target  and  the  target  density.  Equations  3.20  and  3.21  show 
these  modified  equations: 

AtJ  =  V„v,Prii£§f-)  VJ,i  (3.20) 

Cji  =A,v,P|(^)  Vi,y  (3.21) 

where  L  is  the  lethal  area  of  one  round  from  weapon  type  i  or  j 
D  is  the  total  target  area  of  the  Blue  or  Red  unit. 
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Finally,  Equation  3.18  or  3.20,  as  appropriate  to  the  type  of  fire,  is 
substituted  into  Equation  3.14  for  Blue  force  attrition,  and  Equation  3.19  or 
3.21  is  substituted  into  Equation  3.15  for  Red  force  attrition. 

4.  Interdiction 

Red  interdicts  Blue  s  lines  of  communication,  intermodal  infrastructures, 
and  convoys  according  to  a  Poisson  Process  whose  rate  is  set  by  the  user.  Figure 
3.5  shows  Red’s  interdiction  process. 

When  an  infrastructure  interdiction  occurs,  RSO&I  and  Blue  movement 
through  the  affected  structure  halts.  When  convoys  are  interdicted,  the  fraction 
of  the  requisition  proportional  to  the  fraction  of  the  convoy  destroyed  is  also 
destroyed.  A  requisition  then  enters  the  depot  system  for  the  destroyed 
amount.  The  destroyed  convoy  units  are  removed  as  potential  resources  from 
the  depot  transportation  queue  from  which  they  were  borrowed.  They  are  not 
replaced  until  that  depot  transportation  queue  experiences  a  transport  shortfall 
and  requisitions  more  units  for  its  queue. 


Figure  3.5.  Red  Interdiction  Process.  Interdiction  occurs  at  rate  /),  set  by  the  user. 

The  determinator,  x,  between  convoy  and  infrastructure  interdiction  is  also  set  by  the 
user. 
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5.  Interdiction  Repair 

When  intermodal  infrastructure  is  damaged.  Blue  engineer  units 
are  ordered  on  scene  to  repair  the  damages.  Estimates  for  the  times  of  repair 
and  amounts  of  construction  materiel  consumed  are  based  upon  the  capabilities 
of  the  Army’s  Corps  of  Engineers,  the  Navy’s  Seabees,  and  the  Air  Force’s  Red 
Horse  Squadrons  to  repair  standard  types  of  battle  damage  or  install  temporary 
replacement  structures. 
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IV.  THE  SIMULATION 


The  model  is  implemented  in  MODSIM  II,  an  object-oriented  simulation 
language  that  structures  both  synchronous,  or  consecutive,  program  execution 
and  asynchronous,  or  simultaneous,  program  execution  to  occur  seamlessly  [Ref 
3].  The  result  is  that  the  four  consumption  mechanisms  and  logistics  RSO&I 
occur  concurrently,  as  they  would  in  a  real  world  campaign.  The  code  may  be 
downloaded  from  the  Internet  by  following  links  at 
http:\\dubhe.cc.nps.navy.mil\~ahbuss. 

A  run  of  the  model  is  made  after  the  user  has  designated  the  forces  on 
both  sides,  the  rate  at  which  interdiction  occurs,  and  what  depots  are  available 
to  Blue  forces.  The  simulation  is  run  until  the  desired  confidence  interval  is 
obtained.  The  initial  data  are  reset  prior  to  each  new  run  of  the  model.  The 
next  sections  describe  the  implementation  of  the  model  using  MODSIM  II. 

A.  DATA  STRUCTURE 

The  data  structure  follows  the  form  shown  in  Figure  3.2.  Figure  B.l  of 
Appendix  B  shows  how  the  data  structure  has  been  implemented  in  code. 

B.  MOVINGOBJ  STATE  SPACES 

MODSIM  has  some  peculiarities  in  how  it  interrupts  object  activities 
once  they  have  begun  asynchronous  activities.  Suppose,  for  instance,  a  Blue  unit 
pauses  at  a  site  before  proceeding.  While  Blue  is  paused,  a  Red  unit  closes,  a 
detection  occurs,  and  the  two  units  fight.  In  order  for  the  code  to  support  this 
sequence  of  events,  it  must  interrupt  both  Blue’s  wait  and  Red’s  advance,  and 
then  send  both  of  them  into  a  fight.  Several  problems  arise.  MODSIM  must 
know  to  interrupt  Blue’s  wait  procedures  and  not  its  move  procedures,  and 
interrupt  just  the  opposite  procedures  for  Red.  Furthermore,  once  the  two 
MovingObj’s,  introduced  in  Figure  3.2,  are  interrupted,  each  must  "know”  what 
caused  the  interruption  to  “know”  what  to  do. 

The  model  assigns  a  numeric  state  to  each  MovingObj,  determined  by  the 
status  of  several  conditions,  that  compels  it  to  perform  one  of  four  activities: 
move,  fight,  wait,  or  withdraw.  Conditions  to  which  both  sides  are  subject  are 
contact  with  another  MovingObj,  arrival  at  the  final  destination,  and  an  imposed 
wait  at  an  intermediate  destination.  The  imposed  wait  is  a  condition 
experienced  when  a  unit  arrives  at  a  destination  and  waits  before  proceeding,  as 
described  in  Chapter  III,  Section  D.  Blue  checks  the  further  conditions  of 
sufficient  subsistence,  POL,  and  ammunition  on  hand. 
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For  example,  if  a  Blue  unit  is  not  waiting  at  a  site,  has  not  reached  its 
objective,  has  sufficient  subsistence,  POL,  and  ammunition,  and  has  not 
detected  another  MovingObj,  it  should  advance.  This  set  of  conditions  is  unique 
to  state  14  and  maps  onto  an  action  to  advance.  Tables  4.1  and  4.2  show  the 
conditions,  their  corresponding  states,  and  the  actions  onto  which  the  states 
map. 


Delay 

At 

Objective 

Subsistence 

POL 

Ammo 

Contact 

Option 

Result 

+/-  32 

+/-  16 

+/-  8 

+/-  4 

+/-  2 

+/-1 

0 

0 

0 

0 

0 

0 

0 

Wait 

0 

0 

0 

0 

0 

1 

1 

Wait 

0 

0 

0 

0 

1 

0 

2 

Wait 

0 

0 

0 

0 

1 

1 

3 

Fight 

0 

0 

b 

1 

0 

0 

4 

Wait 

0 

0 

0 

1 

0 

1 

5 

Withdraw 

0 

0 

0 

1 

1 

0 

6 

Wait 

0 

0 

0 

1 

i 

1 

7 

Fight 

0 

0 

1 

0 

0 

0 

8 

Wait 

0 

0 

1 

0 

0 

1 

9 

Wait 

0 

0 

i 

0 

1 

0 

10 

Wait 

0 

0 

1 

0 

1 

1 

11 

Fight 

0 

0 

1 

1 

0 

0 

12 

Wait 

0 

0 

1 

1 

0 

1 

13 

Withdraw 

0 

0 

1 

1 

1 

0 

14 

Advance 

0 

0 

1 

1 

1 

1 

15 

Fight 

0 

1 

0 

0 

0 

0 

16 

Wait 

0 

1 

0 

0 

0 

1 

17 

Wait 

0 

1 

0 

0 

1 

0 

18 

Wait 

0 

1 

0 

0 

1 

1 

19 

Fight 

0 

1 

0 

1 

0 

0 

20 

Wait 

0 

1 

0 

1 

0 

1 

21 

Withdraw 

0 

1 

0 

1 

1 

0 

22 

Wait 

0 

1 

0 

1 

1 

1 

23 

Fight 

0 

1 

1 

0 

0 

0 

24 

Wait 

0 

1 

1 

0 

0 

1 

25 

Wait 

0 

1 

1 

0 

1 

0 

26 

Wait 

0 

1 

1 

0 

1 

1 

27 

Fight 

0 

1 

1 

1 

0 

0 

28 

Wait 

0 

1 

1 

1 

0 

1 

29 

Withdraw 

0 

1 

1 

1 

1 

0 

30 

Wait 

0 

1 

1 

1 

1 

1 

31 

Fight 

Table  4.1.  State  Spaces.  Six  conditions  define  the  state  of  an  object.  The 
state  determines  what  the  object  will  do.  States  0  to  31  are  non-imposed 
wait  states.  Rows  show  how  the  status  of  each  condition  is  used  to  form 
the  unique  binary  number  associated  with  a  particular  state. 
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Delay 

mm 

Result 

+/-  32 

+/-  16 

+/-8 

+/-  4 

+/-  2 

+/-1 

1 

6 

0 

0 

0 

32 

Wait 

1 

0 

IBS 

1 

33 

Wait 

1 

0 

0 

0 

1 

IHBH 

34 

Wait 

1 

6 

0 

0 

1 

1 

35 

1 

0 

0 

1 

36 

Wait 

1 

0 

0 

1 

0 

1 

Withdraw 

1 

0 

0 

1 

1 

0 

38 

Wait 

1 

0 

0 

1 

1 

1 

39 

■sum 

1 

0 

1 

0 

40 

Wait 

1 

0 

1 

0 

0 

1 

41 

Wait 

1 

0 

1 

0 

1 

0 

42 

1 

1 

1 

1 

43 

■ 

1 

0 

1 

1 

0 

0 

44 

Wait 

1 

0 

1 

1 

0 

1 

45 

1 

0 

1 

1 

1 

0 

46 

| 

1 

0 

1 

1 

1 

1 

47 

H9H3SI 

1 

1 

0 

0 

0 

0 

48 

Wait 

1 

1 

0 

0 

0 

1 

49 

Wait 

1 

1 

0 

0 

1 

0 

50 

Wait 

1 

1 

0 

1 

1 

51 

HE3539H 

1 

1 

0 

1 

6 

52 

Wait 

1 

1 

1 

1 

53 

Withdraw 

1 

1 

0 

1 

1 

0 

54 

Wait 

1 

1 

0 

1 

1 

1 

55 

1 

1 

1 

0 

0 

0 

56 

Wait 

1 

1 

1 

0 

0 

1 

57 

Wait 

1 

1 

1 

0 

1 

58 

Wait 

1 

1 

1 

0 

1 

1 

59 

1 

1 

1 

1 

0 

0 

60 

Wait 

1 

1 

1 

1 

0 

1 

61 

Withdraw 

1 

1 

1 

1 

1 

0 

62 

Wait 

1 

1 

1 

1 

1 

1 

63 

Fight 

Table  4.2.  State  Spaces  (continued).  States  32  to  63  occur  when  the  object 
conducts  an  imposed  wait.  Any  state  greater  than  2s  is  a  dormant  state 


The  state  approach  is  based  upon  two  guiding  principles: 

1.  An  object  must  be  doing  something  that  can  be  interrupted  if  it  is 
to  be  interrupted. 

2.  An  object  in  a  state  remains  in  that  state  until  directed  to  change. 
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The  application  of  the  first  principle  is  the  ability  of  the  code  to  interrupt 
the  specific  action  that  the  MovingObj  is  performing.  In  the  example,  the  code 
“knows”  to  interrupt  Red’s  move  procedures  because  Red’s  state  is  14. 
Furthermore,  because  of  the  second  principle,  the  code  can  determine  the 
appropriate  time  to  interrupt  Red’s  move  procedure.  Continuing  the  example, 
the  code  directs  both  Red  and  Blue  to  change  their  states  to  a  Fight  state  by 
interrupting  their  individual  current  activity  when  the  detection  occurs  and 
ordering  each  to  increase  its  state  by  1.  Both  objects  remain  in  a  Fight  state 
until  one  of  the  basic  conditions  for  at  least  one  object  changes  and  precipitates 
a  new  state  other  than  Fight.  If  Blue  expends  its  ammunition  in  the  heat  of 
combat,  but  still  has  POL,  then  its  Ttatechange  should  compel  it  to  Withdraw. 

Its  Fight  is  interrupted  with  an  ordered  “state  change  to  Withdraw,  and  retreat 
occurs. 

The  code  can  determine  an  object’s  state  mathematically  because  each 
state  is  represented  by  a  unique  binary  number  based  upon  the  conditions 
shown  in  Tables  4.1  and  4.2,  which  are  themselves  binary.  The  code  uses  the 
decimal  conversion  of  the  binary  number  as  the  object’s  state.  Whenever  a 
condition  changes,  the  decimal  state  also  changes.  For  instance,  an  object  that 
runs  out  of  POL  has  a  state  change  of  -4  since  POL  is  in  the  22  column  of  Tables 
4.1  and  4.2. 


Considering  the  example  again  from  the  startrthe  Blue  rniit  halts  at  a  site 
while  the  Red  unit  travels  towards  it.  Blue’s  state  is  46  (Wait)  while  Red’s  state 
is  14  (Move).  Both  increase  their  state  by  1  when  contact  occurs.  Also,  in  the 
case  where  an  imposed  delay  is  interrupted,  the  delay  is  lifted,  with  a 
corresponding  change  in  state  of  -32.  The  net  change  for  Blue  is  -31.  Both 
states  are  now  15  (Fight).  If  Blue  runs  out  of  ammunition,  its  state  becomes  13 
(Withdraw).  As  the  Withdraw  occurs,  contact  is  lost  and  the  new  states  are  12 
(Wait  caused  by  no  ammunition),  and  14  (Move)  for  Red.  When  Blue 
replenishes  its  ammunition,  its  state  changes  to  14  and  it  advances. 

One  final  action  for  MovingObj’s  must  be  considered.  Each  of  the  four 
actions  (Move,  Withdraw,  Fight,  and  Wait)  causes  events  to  be  scheduled  on 
MODSIM  s  event  list.  The  result  is  that  the  program  will  continue  forever,  well 
after  the  Red  is  vanquished  and  Blue  holds  the  objective.  Accordingly,  a  final 
state,  the  dormant  state,  is  added  as  state  65.  The  dormant  state  does  not 
schedule  new  events  for  the  object.  However,  since  a  unique  state  is  identified, 
the  dormant  object  may  be  recalled  into  active  scheduling  at  any  time.  When  all 
of  the  MovingObj  s  in  the  program  have  become  dormant,  further  scheduling  on 
the  event  list  ceases  and  the  program  terminates.  A  Blue  unit  will  become 
dormant  if  a  state  change  to  30  or  62  occurs. 
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C.  PROGRAM  COMMAND,  CONTROL,  AND  COMMUNICATIONS 

The  model  implementation  uses  two  controlling  authorities.  The  main 
program  contains  the  data  collection  shell  which  directs  the  individual  runs  of 
the  model  and  collects  the  data  from  them.  An  entity  called  a  RefereeObj  is 
created  to  control  Blue  and  Red  actions  within  a  model  run. 

1.  Data  Collection  Shell 

The  data  collection  shell  serves  the  administrative  function  of  collecting 
the  data  destined  to  form  the  confidence  intervals  and  to  provide  data  structure 
continuity  from  nm  to  run. 

2.  The  Referee 

Each  Blue  and  Red  force  component  has  a  data  structure  that  supports 
only  those  functions  that  the  MovingObj  needs  to  know  or  do.  For  instance,  a 
MovingObj  “knows”  what  its  mission  is.  From  this  it  can  compute  how  long  it 
will  take  to  arrive  at  the  next  intermediate  destination  and  how  much  fuel  it  will 
use  getting  there.  It  does  not  “know”  if  it  will  come  into  contact  with  opposing 
side  components  along  the  way  because  it  has  no  data  structure  in  which  to 
store  this  information.  This  approach  maintains  a  consistency  between 
simulation  entities  and  the  real  world  units  being  modeled.  In  the  real  world 
sense,  this  is  analogous  to  a  combat  unit  that  has  full  knowledge  of  its  own 
state,  but  no  knowledge  of  the  patrol  it  is  seeking. 

The  RefereeObj  is  a  nearly  omniscient  element  in  the  model  rim.  It  is  the 
repository  for  all  of  the  various  data  structures  and  the  clearinghouse  for  Blue 
and  Red  MovingObj  actions.  In  this  capacity,  the  RefereeObj  can  access  all  of 
the  information  relevant  to  the  model  run  and  communicate  it  to  Blue  and  Red 
forces  on  a  need-to-know  basis.  In  the  example,  the  RefereeObj  notifies  both 
the  Blue  and  Red  components  that  they  have  made  contact  during  Blue’s  move. 

In  its  role  as  the  clearinghouse  for  all  MovingObj  actions,  the  RefereeObj 
oversees  and  administers  state  changes  for  the  MovingObj’s.  Once  the 
RefereeObj  has  directed  a  MovingObj  to  change  its  state,  it  directs  the 
MovingObj  to  start  that  state’s  activity:  to  move,  fight,  withdraw,  or  to  wait. 
The  RefereeObj  then  gives  the  MovingObj  access  to  any  data  it  needs  to  carry 
out  the  action  or  to  handle  an  interrupt.  The  following  sections  describe  the 
methodology  through  which  the  MovingObj  performs  its  actions. 
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The  RefereeObj  uses  an  Oracle  mechanism  to  order  the  MovingObj  to 
action.  Essentially,  the  MovingObj  is  "aware”  that  its  state  has  changed  and 
consults  the  RefereeObj  as  an  oracle  to  "determine”  what  to  do.  This  process 
is  depicted  in  Appendix  B,  Figure  B.6.  and  is  coded  in  RefereeObj.Oracle. 

The  basic  idea  for  a  MovingObj  action  is  for  the  RefereeObj  to  tell  it  to 
prepare  to  perform  that  action.  The  MovingObj  then  makes  any  necessary 
calculations,  including  how  long  to  perform  the  action,  before  asking  permission 
from  RefereeObj  to  perform.  The  RefereeObj  checks  for  potential  conflicts  and 
orders  the  MovingObj  to  act.  When  the  MovingObj  completes  its  action,  any 
update  bookkeeping  is  done,  the  new  state  is  assigned,  and  the  MovingObj 
consults  the  RefereeObj.  The  RefereeObj  tells  it  to  request  permission  to 
perform  the  new  state  and  the  cycle  starts  anew.  When  an  action  must  be 
interrupted,  the  RefereeObj  waits  until  the  correct  time  and  then  interrupts  the 
MovingObj.  If  the  reason  for  the  interrupt  involves  another  MovingObj  then 
die  interrupting  MovingObj  is  interrupted  as  well,  and  both  objects  are  told  of 
die  other’s  presence.  Any  bookkeeping  is  done  and  the  object  consults  the 
RefereeObj.  Figure  B.7  in  Appendix  B  shows  the  interrupt  process. 

For  example,  suppose  a  Blue  MovingObj  wishes  to  move  to  a  specified 
location.  The  MovingObj  computes  how  much  POL  it  requires  and  how  much 
tune  it  will  spend  enroute.  The  MovingObj  asks  the  RefereeObj  for  permission 
to  move.  The  RefereeObj  then  checks  for  conflicts.  In  this  case,  the  potential 
conflicts  are  meeting  a  Red  unit,  running  out  of  POL,  or  finding  a  convoy 
delivering  goods  to  it.  The  time  of  the  conflict  is  computed.  If  several  potential 
conflicts  are  possible,  only  the  soonest  time  is  retained.  After  the  time  of  the 
first  conflict  is  determined,  the  RefereeObj  tells  the  unit  to  move  to  the  specified 
location.  The  RefereeObj  interrupts  the  MovingObj  at  the  appropriate  time  if 
the  first  conflict  occurs  before  the  MovingObj  arrives  at  its  destination.  The 
unit  consumes  the  POL  used  to  the  time  of  interrupt.  If,  for  instance,  the 
interrupt  was  due  a  low  fuel  state  the  unit  is  told  to  request  to  wait  when  it 
consults  the  oracle.  In  this  case,  the  unit  will  wait  until  a  fuel  convoy  finds  it 
and  refuels  it...if  a  Red  unit  does  not  find  it  first.  If  there  is  no  conflict,  then  the 
unit  completes  its  move  and  consumes  the  calculated  POL. 

D.  IMPLEMENTING  THE  FUNCTIONAL  AREAS 

1*  Logistics  Flow  Model  Modules 

The  Pr°gram  uses  ten  modules  to  handle  the  administration  and 
bookkeeping  processes  and  to  conduct  the  five  functional  areas. 
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1.  ShellObj.  ShellObj  implements  the  data  collection  shell. 

2.  RefereeObi.  RefereeObj  contains  the  code  for  the  actions 
performed  by  the  Referee. 

3.  MovingObj.  A  MovingObj  is  the  base  object  for  all  objects  that 
move.  MovingObj  contains  the  code  inherited  by  all  objects  that  move. 

4-  OrderOfBattle.  OrderOfBattle  homeports  Blue  combat  units  and 
engineers,  and  Red  opposition  force  objects.  All  three  are  children  of  UnitType, 
a  direct  descendant  of  MovingObj.  OrderOfBattle  also  contains  the  Force  group 
object.  As  a  group  object.  Force  acts  as  a  "bucket”  for  each  side  into  which  all  of 
each  side’s  units  are  placed. 

5.  Logistics  1.  Logistics  1  contains  the  code  implementing  the  Depot 
System.  It  also  encodes  the  TransportObj’s;  Blue  children  of  MovingObj  who 
move  logistics  materiel  from  the  depots  to  the  combat  units  and  engineers. 

6.  MapStructure.  MapStructure  implements  the  network 
representation  of  the  map  used  in  the  model.  It  also  handles  all  of  the 
bookkeeping  for  sites,  terminals,  and  arcs  when  they  are  captured,  interdicted, 
and  repaired. 

7.  BattleData.  BattleData  is  a  field  of  UnitType  that  defines  a 
UnitType’s  combat  identity.  BattleData  is  a  bucket  for  the  class  WeaponObj,  an 
object  that  represents  the  combat  modeling  characteristics  of  a  single  weapon 
system. 

8*  FileManager.  FileManager  is  an  administrative  module  that 

expands  the  built-in  input/output  and  file  handling  capabilities  of  MODSIM  II 
to  dovetail  with  the  needs  of  the  code.  All  files  input  and  output  is 
accomplished  using  a  FileManager  object  named  FileTracker. 

9.  Uncertainty.  Uncertainty  enacts  the  class  UncertainObj,  a 
derivative  of  MODSIM’s  RandomObj.  UncertainObj  expands  the  methods  of 
RandomObj  to  the  needs  of  the  code  and  serves  to  furnish  the  model  with 
random  numbers  when  needed. 

10.  SimpleStats.  SimpleStats  is  used  within  the  ShellObj  to  maintain 
the  collected  MOE  data  and  compute  the  desired  statistics. 
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2.  Logistics  Flow 


Two  elements  work  together  to  spur  the  logistics  flow:  consumption  and 
RSO&I.  Both  elements  are  coded  as  a  direct  reflection  of  the  model  descriptions 
in  Chapter  III,  Section  D.  Blue  consumption  is  tracked  either  continuously  or  by 
events  of  usage  depending  upon  which  MOE  is  being  used  with  that  materiel. 
Table  3.1  cataloged  the  aggregated  classes  of  supply  into  five  aggregates: 
subsistence,  super,  POL,  ammunition,  and  major  items. 

Subsistence  and  super  are  continuous  consumption  items  for  Blue  units, 
although  Blue  engineers  also  track  those  construction  materiel  in  the  super  class 
when  they  are  repairing  infrastructure.  All  Blue  units  begin  scheduled 
subsistence  and  super  consumption  when  a  model  run  starts  and  ceases  when 
the  Blue  units  become  dormant.  In  this  process,  consumption  occurs  every  24 
hours. 


Event  use  items  are  conditional  use;  POL,  ammunition,  and  major  items 
are  tracked  each  time  an  event  occurs  that  uses  that  commodity.  POL  is 
expended  whenever  a  Blue  MovingObj  stops  movement,  either  by  reaching  its 
destination,  or  by  interruption.  The  quantity  of  ammunition  delivered  against 
Red  units  is  a  function  of  the  ammunition  type’s  firing  weapon’s  firing  rate  and 
the  length  of  the  fight.  Major  items  are  tracked  when  they  are  destroyed  and 
require  special  comment:  each  TransportObj  and  WeaponObj  must  have  a 
corresponding  entry  in  the  major  class  so  that  RSO&I  for  these  items  may  also 
occur.  In  other  words,  if  a  Blue  division  has  300  artillery  pieces  (WeaponType 
Arty)  in  its  WeaponsList  (See  Appendix  B,  Figure  B.2,  Data  Structure  Map  for 
UnitType),  then  its  UnitLoadOut  also  will  show  300  artillery  pieces.  When  the 
combat  module  attrites  these  artillery  pieces  from  the  WeaponsList,  they  are 
consumed  as  logistics  commodities  as  well.  This  duality  provides  the  necessary 
link  to  replace  major  items  destroyed  in  combat  or  by  interdiction.  Note  also 
that  infantry  are  considered  as  both  major  items  and  as  a  WeaponType.  This 
allows  replacement  personnel  to  enter  into  the  theater. 

Any  process  of  consumption  causes  the  unit  to  reorder  the  commodity  if 
the  amount  on  hand  plus  the  amounts  of  all  of  the  requisitions  on  order  falls 
below  a  user  defined  percent  of  that  commodity’s  maximum  capacity.  RSO&I  is 
triggered  in  this  way,  as  is  the  data  collection  routine.  The  event  of  commodity 
consumption,  found  in  Logistics  l.LoadListObj.ConsumeCommodity  of 
Appendix  B,  Figure  B.4,  passes  the  necessary  information  to  the  ShellObj  using 
the  RefereeObj  as  a  messenger  so  that  the  usage  data  can  be  recorded. 
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3. 


Blue  and  Red  Movement 


MovingObj’s  move  on  command  from  the  Referee  after  making  the 
required  calculations.  Each  MovingObj  calculates  its  enroute  time  to  the  next 
destination  based  upon  the  grid  distance  between  its  initial  and  planned  final 
locations  and  the  user-defined  travel  speed  for  the  terrain  type  between  the  two 
points.  Blue  MovingObj’s  also  compute  how  much  fuel  is  needed  for  the  entire 
trip.  In  the  event  that  the  MovingObj  does  not  have  enough  fuel  for  the  trip,  it 
is  still  ordered  to  move  by  the  Referee  and  will  run  out  of  POL  along  the  way. 
This  is  analogous  to  a  combat  unit  that  must  advance,  but  may  not  have 
logistics  support  at  its  destination. 


4.  Blue  and  Red  Combat 

The  Fight  state  spans  elements  of  movement,  logistics  flow,  and  combat. 
The  detection  algorithm  of  Chapter  III,  Section  F.3  determines  if  Blue  and  Red 
units  intercept  each  other,  or  when  a  Blue  convoy  has  found  its  Blue  unit 
customer.  In  either  event  the  objects  concerned  transition  to  a  Fight  state.  If 
Blue  and  Red  units  are  involved,  attrition  occurs.  If  Blue  and  Blue  units  are 
involved,  then  replenishment  occurs. 

The  program  calculates  Blue  and  Red  attrition  according  to  Chapter  III, 
Section  F.  In  practice,  when  Blue  and  Red  fight,  the  attrition  calculations  are 
made  in  OrderOfBattle.OpForce.Fight.  Although  both  Blue  and  Red  are  in  a 
Fight  state,  and  executing  the  code  in  OrderOfBattle.CombatForce.Fight  and 
OOB.OpForce.Fight,  the  actual  attrition  calculations  are  made  one  time  in 
OpForce.Fight  while  Blue  waits  in  CombatForce.Fight  to  prevent  double 
attrition  from  occurring. 


The  duration  of  the  fight  is  a  function  of  each  side’s  killing  rate  against 
the  other,  and  each  side’s  breakpoints.  The  rate  at  which  a  particular  weapon  is 
attrited  by  all  opposition  weapons  firing  at  it  follows  Equation  3.14  or  3.15. 
User  defined  databases  indicate  whether  a  weapon  type  on  weapon  type  is  aimed 
fire  or  area  fire,  and  therefore,  which  of  Equations  3.18-3.21  to  use  for  the 
casualty  rate  in  Equation  3.14  or  3.15.  Database  information  also  tells  Blue 
what  ammunition  type  to  use. 


One  side’s  force  breakpoint  is  determined  as  a  function  of  the  component 
weapon  type  breakpoints.  The  database  gives  a  minimum  percent  of  a  weapons 
starting  strength  as  its  breakpoint.  Blue’s  ammunition  expenditures  are 
calculated  in  a  fashion  similar  to  Equations  3.15  in  which  the  time  rate  of 
depletion  is  a  linear  function  of  the  each  weapon’s  firing  rate  and  the  number  of 
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weapons  firing  that  ammunition  type.  The  times  for  ammunition  expenditure 
are  computed  as  a  function  of  amount  on  hand  and  the  total  force  rate  of 
expenditure.  Blue  times  to  systems  breakpoints  actually  become  the  sooner  of 
weapon  breakpoint  and  ammunition  depletion. 

The  databases  also  tell  the  model  how  many  of  a  force’s  weapons  must 
fall  to  breakpoint  before  the  entire  force  reaches  breakpoint.  As  a  result,  if  a 
force  can  sustain  3  of  4  systems  at  breakpoint  before  disengaging,  up  to  two 
systems  may  be  far  below  their  individual  breakpoint  when  contact  is  broken. 
Since  Equations  3.14  and  3.15  are  linear,  setting  the  equation  equal  to  a 
system  s  permissible  casualties  gives  the  time  to  its  breakpoint.  If  the  m 
breakpoint  times  for  the  m  systems  are  then  sorted  in  ascending  order,  a  force 
capable  of  sustaining  k  of  m  breakpoints  reaches  force  breakpoint  at  the  feth 
ordered  breakpoint.  Whichever  side’s  force  breakpoint  happens  first  determines 
the  winner  and  the  loser.  Batde  casualties  are  calculated  by  multiplying 
Equation  3.14  and  3.15  with  the  time  to  the  first  force  breakpoint.  Both  sides 
are  directed  to  apply  a  state  change  appropriate  to  the  outcome  of  the  fight. 

5.  Red  Interdiction  of  Blue  Intermodal  Infrastructure  and  RSO&I 

Red  interdicts  Blue  Intermodal  Infrastructure  in  a  direct  coding  of 
Chapter  III,  Section  4  methodology  and  accompanying  figure.  Interdiction 
occurs  as  a  Poisson  Process,  whose  rate,  lambda,  is  specified  by  the  user.  The 
code  is  found  in  OrderOfBattle.Force.Interdict. 

E.  MODEL  OUTPUTS 

The  code  offers  a  variety  of  output  files  useful  for  diagnostics  and  insights 
to  the  workings  of  the  model.  Two  of  these  output  files,  the  War  Diary  and  the 
Supply  Diary,  are  given  in  Appendix  C  for  one  of  the  cases  presented  in  Chapter 

1 .  Database  Echoes 

The  Red  and  Blue  Force  dump  their  contents  to  a  file.  This  dump  lists 
each  UnitType  in  the  force,  including  the  weapons  characteristics  for  each 
weapon  system  assigned  to  that  unit.  This  is  useful  whenever  new  databases  are 
used  to  verify  that  the  program  has  correctly  constructed  the  data  structure.  The 
map  can  also  be  dumped  in  the  same  fashion  for  each  run. 
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2. 


Diaries 


Three  history  files  are  produced  for  each  model  run.  Two  of  these  are  the 
War  Diary  and  the  Supply  Diary.  The  War  Diary  is  a  listing  of  all  non-supply 
related  events  that  happen  to  every  MovingObj  in  a  rim.  For  instance,  the  Diary 
lists  each  time  a  MovingObj  leaves  and  arrives  a  destination,  is  delayed  enroute, 
or  detects  another  MovingObj.  The  Diary  also  logs  the  times  and  locations  of 
infrastructure  interdiction  and  repair. 

The  Supply  Diary  logs  each  event  that  consumes  commodities,  places 
orders  and  backorders,  forms  convoys,  and  delivers  materiel.  Since  the  two 
Diaries  also  list  the  time  of  occurrence,  they  can  be  compared  with  each  other 
for  a  complete  picture  of  the  logistics  flow  for  an  individual  model  run. 

A  third  historical  file,  a  State  log,  can  be  produced  for  each  MovingObj  if 
desired.  This  Diary  logs  each  State  change  of  the  object  with  the  time  of  change, 
the  current  State,  and  the  new  State.  This  is  a  valuable  diagnostic  tool  that  is 
controlled  using  a  MovingObj’s  StateFlow  FileTracker. 

3.  Statistical  Files 

Each  Blue  event  of  commodity  consumption  generates  two  data  points: 
the  amount  used  and  the  amount  remaining  on  hand.  These  data  are  collected 
by  the  ShellObj  and  provide  the  confidence  interval  statistics  and  MOE’s  for 
each  simulation.  The  times  of  capture  by  Blue  for  each  site  are  also  collected. 
Examples  of  this  output  are  given  in  Chapter  V. 
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V.  MODEL  DEMONSTRATION 


A.  PURPOSE  OF  THE  DEMONSTRATION 

Chapter  III  and  IV  developed  the  proposed  model  and  explained  its 
implementation  into  MODSIM.  This  chapter  showcases  how  the  proposed 
model  performs  by  using  three  cases  of  increasing  complexity  to  exercise  its 
features  and  functions.  The  results  of  these  cases  are  explained  in  terms  of  how 
logistics  affected  Blue’s  mission,  and  what  happened  in  the  model  to  cause  these 
effects. 

B.  COMMON  SCENARIO  AND  DATABASES 

In  the  course  of  a  war  with  Red,  Blue  lands  a  division  in  the  RedLand 
port  city  of  Houston  whose  objective  is  the  small  town  of  Plainview,  about  six 
hundred  miles  to  the  north-northwest.  The  port  city  serves  as  the  FLB.  Red, 
caught  unaware  by  Blue’s  amphibious  landing,  has  only  a  division  sized  force 
garrisoned  near  Plainview.  They  rally  quickly  and  march  on  Blue  to  force  a 
decisive  battle  and  interdict  Blue’s  lines  of  communication  and  supply  convoys 
in  the  meantime. 

The  various  databases  necessary  to  run  the  model  are  contained  in 
Appendix  D.  Each  database  has  a  description  of  its  purpose.  The  databases 
explain  any  unique  format  considerations.  The  numbers  used  for  some 
elements  are  artificially  high  or  low  to  slow  the  campaign  so  that  RSO&I  is 
more  fully  exercised. 

The  databases  use  a  depot  system  with  a  FLB  in  Houston  and  two 
intermediate  depots  in  Abilene  and  Lubbock.  The  Abilene  depot  carries  mostly 
POL,  while  the  depot  in  Lubbock  carries  some  subsistence.  The  two 
intermediate  depots  are  used  primarily  to  show  the  depot  requisition  processing 
system  that  receives  requisitions  at  the  nearest  depot  to  the  troops  and  then  fills 
or  backorders  as  required. 

C.  MODEL  CASES 

One  baseline  and  two  variant  cases  are  considered  in  determining  the 
level  of  logistical  support  the  supported  units  might  expect  from  the  FLB  and 
the  intermodal  infrastructure.  An  instruction  in  RefereeObj.Oracle  terminates  a 
model  run  if  the  time  exceeds  120  days,  an  event  in  which  Blue’s  advance  has 
stalled.  Each  case  uses  the  same  databases  given  in  Appendix  D. 
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1. 


Baseline 


A  baseline  case  establishes  the  logistics  support  that  the  supported  units 
will  have  when  the  FLB  and  lines  of  communication  operate  at  full  capacity  in  an 
undamaged  state.  In  an  actual  conflict,  the  baseline  case  is  unlikely  since  it  is 
doubtful  any  site  with  permanent  infrastructure  can  be  captured  from  the  enemy 
entirely  intact.  The  baseline  case  is  germane,  however  because  a  damaged  FLB 
operating  at  reduced  capacity  cannot  be  expected  to  sustain  the  supported 
troops  if  a  fully  functional  base  cannot  either. 

a.  Model  Implementation 

The  baseline  case  exercises  all  of  the  model  except  for  combat 
attrition  calculations,  and  intermodal  infrastructure  and  convoy  interdiction.  It 
also  demonstrates  the  statistics  functions  of  the  ShellObj  and  the  controlling 
functions  of  the  RefereeObj.  The  application  of  the  baseline  to  the  model 
initializes  the  only  the  Blue  force  data  structures  from  the  force  databases. 

The  probabilistic  elements  of  the  baseline  case  are  the  travel  time 
delays  and  usage  adjustments  introduced  in  Chapter  III.  The  travel  times  are 
deterministic 

The  expectation  for  the  baseline  case  is  to  show  the  division’s 
movement  from  Houston  to  Plainview  replicated  many  times  in  order  to 
generate  statistics  for  Class  I  subsistence  and  Class  II  POL,  the  two  aggregated 
classes  used. 


b.  Results 

Three  hundred  model  runs  produced  the  results  shown  in  Tables 
5.1,  5.2,  and  5.3.  Table  5.1  shows  the  collected  statistics  for  the  site  capture 
times.  Tables  5.2  and  5.3  shows  the  collected  statistics  for  logistics  materiel. 


Location 

N 

Mean 

(Hours) 

Houston 

300 

0.0 

Abilene 

300 

19.1 

Sweetwater 

300 

40.0 

Lubbock 

300 

45.7 

Abernathy 

300 

70.6 

Plainview 

300 

88.8 

a 

StdDev 

Min 

IVbx 

(Hours) 

(Hours) 

(Hours) 

(Hours) 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

19.1 

19.1 

0.4 

2.0 

30.1 

40.7 

1.0 

4.0 

35.2 

54.5 

2.2 

10.2 

46.7 

86.3 

3.0 

13.1 

51.8 

119.1 

Table  5.1.  Site  Capture  Results.  N  is  the  number  of  times  Blue  captured  the 
site  in  300  model  runs.  Cl  gives  the  95%  confidence  interval. 
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The  effects  of  the  imposed  delays  at  the  intermediate  destinations  can  be  seen  in 
Table  5.1  as  the  increasing  variability  in  site  arrival  times. 

Not  surprisingly,  in  the  absence  of  intervention  and  combat.  Blue 
captured  Plainview  in  every  run,  since  N=300  for  Plainview.  Table  5.2  shows 
the  amounts  of  materiel  that  the  unit  had  remaining  when  it  reported  its  status 
each  time  an  event  of  usage  occurred.  For  commodities  like  subsistence,  whose 


Commodity 

Day 

N 

Mean 

Cl 

StdDev 

Mn 

Max 

(STOfMS) 

(STONS) 

(STONS) 

(STONS) 

(STONS) 

Class  1:  Subsistence 

CRAT 

0 

300 

100000.0 

0.0 

0.0 

100000.0 

100000.0 

1 

300 

59948.2 

367.8 

1624.9 

55424.0 

64534.0 

2 

300 

48832.0 

3277.4 

14481.3 

25560.0 

64245.0 

3 

262 

19926.5 

574.0 

2370.2 

12377.0 

25433.0 

4 

43 

19846.6 

1086.6 

1817.6 

14960.0 

24045.0 

Event 

Class  HI:  POL 

Motor 

0 

300 

12000.0 

0.0 

0.0 

12000.0 

12000.0 

1 

300 

5884.1 

55.4 

245.1 

4928.0 

6574.0 

2 

300 

10011.5 

473.6 

2092.8 

3976.0 

11968.0 

3 

300 

8613.8 

367.8 

1624.9 

3673.0 

11446.0 

4 

300 

7642.0 

282.2 

1246.8 

2704.0 

11852.0 

Table  5.2.  Status  of  Materiel  On  Hand.  This  table  shows  the  remaining 
amounts  of  materiel  the  unit  reported  after  each  event  of  usage.  The  second 
column  is  the  day  of  the  campaign  for  subsistence,  and  the  event  of  usage  for 
POL.  Here,  the  results  for  C-rations  and  motor  fuel  are  given.  No  data  are 
given  for  ammunition  since  combat  did  not  occur. 


Commodity 

Day 

N 

Mean 

a 

StdDev 

Mn 

Max 

DOS 

(STONS) 

(STONS) 

(STONS) 

(STONS) 

(STONS) 

Class  1:  Subsistence 

CRAT 

0 

300 

0.0 

0.0 

0.0 

0.0 

0.0 

NA 

1 

300 

40051.8 

367.8 

1624.9 

35466.0 

44576.0 

1.5 

2 

300 

40018.6 

375.2 

1658.1 

35755.0 

44355.0 

1.2 

3 

262 

40040.4 

419.0 

1730.5 

35688.0 

45209.0 

0.5 

4 

43 

40336.9 

765.2 

1280.1 

37082.0 

43190.0 

0.5 

B/ent 

Class  III:  POL 

EOS 

Motor 

0 

300 

0 

0.0 

0 

0 

0 

NA 

1 

300 

6115.9 

55.4 

245.1 

5426 

7072 

1.0 

2 

300 

1209.7 

56.0 

247.8 

32 

1421 

8.3 

3 

300 

1621.1 

24.4 

107.6 

554 

1804 

5.3 

4 

300 

1535.2 

71.4 

315.1 

63 

1801 

5.0 

Table  5.3.  Materiel  usage  summary.  This  table  shows  the  average  short  tons  of  materiel 
used  during  each  event  of  usage.  As  in  Table  5.2,  the  second  column  counts  days  for 
subsistence,  and  event  of  usage  for  POL.  The  appropriate  MOE  for  a  commodity  is  given 
in  the  last  column  as  the  ratio  of  the  ith  day  (event)  amount  remaining  from  Table  5.2 
and  the  corresoondina  averaae  amount  used  in  that  event  from  Table  5.3. 
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MOE  is  measured  in  DOS,  the  second  column  of  Table  5.2  counts  the  day  of  the 
campaign.  For  example,  note  that  every  run  had  at  least  two  days  of  subsistence 
consumption  and  none  had  more  than  four  days.  This  is  consistent  with  Table 
5.1;  in  all  runs,  Plainview  was  captured  no  sooner  than  51.8  hours  into  the 
campaign,  and  no  later  than  119.1  hours.  Viewed  another  way,  the  campaign 
lasted  three  days  in  262  runs,  and  four  days  in  43  runs.  The  second  column  of 
table  shows  that  four  events  of  POL  usage  occurred  in  every  run. 

Table  5.3  tabulates  the  average  amounts  of  each  materiel  that 
were  used  during  each  event.  The  last  column  shows  the  appropriate  MOE  for 
the  materiel.  This  column  shows  that  Blue  started  to  see  the  effects  of 
lengthened  lines  of  communication,  particularly  for  subsistence,  after  day  two. 
A  small  intermediate  fuel  depot  in  Abilene  delayed  this  decline  for  POL  until  the 
third  event  of  usage,  which  placed  Blue  in  Lubbock.  If  the  objective  were 
further,  it  is  likely  that  Blue  would  have  run  out  of  subsistence  along  the  way 
and  been  forced  to  stop  and  await  resupply. 

c.  Model  Performance 

The  baseline  case  highlights  many  of  the  proposed  model’s 
features:  logistics  consumption,  movement,  and  RSO&I,  as~well  as  the 
underlying  processes  of  state  space  operations  and  the  detection  algorithm 
necessary  for  the  features  to  operate  correctly. 

Appendix  C  contains  a  sample  War  Diary  and  Supply  Diary. 
Although  these  Diaries  are  taken  from  a  different  case,  they  also  contain  all  of 
the  features  of  the  baseline  case.  The  Supply  Diary  shows  the  consumption  and 
depot  system  processes  in  action:  materiel  is  expended  and  requisitioned,  and 
convoys  form  when  the  requisitions  are  filled.  The  War  Diary  shows  the 
progress  of  these  convoys  as  they  move  to  resupply  their  customer  units.  The 
amounts  used  and  the  size  of  the  convoys  formed  are  functions  of  the  logistics 
planning  factors  found  in  Appendix  D. 

Each  run  adds  to  the  statistics  forming  Tables  5. 1-5.3.  The  model 
becomes  a  useful  tool  to  the  military  planner  with  these  data.  Table  5.1, 
showing  site  capture  data,  portrays  the  campaign  duration  from  the  logistics 
modeling  point  of  view.  While  not  intended  as  a  timetable  prediction,  the  data 
may  be  useful  for  comparison  with  the  timetables  from  models  like  JTLS,  RESA, 
etc.,  since  they  are  generated  purely  from  logistics  consumption  and  resupply 
considerations  and  not  the  combat  considerations  of  these  models. 


The  real  contribution  of  the  proposed  model  as  a  planning  tool  are 
Tables  5.2  and  5.3  that  show  logistics  requirements  over  the  course  of  the 
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campaign.  The  data  from  various  courses  of  action  may  be  compared  to 
spotlight  courses  that  are  more  feasible  logistically,  as  measured  by  the 
confidence  intervals  and  the  MOE’s.  Considered  for  a  single  course  of  action, 
the  data  provide  entering  arguments  for  planning  and  meeting  campaign 
logistics  requirements. 

2.  Variant  1:  Red  Interdiction 

The  first  variant  of  the  baseline  considers  the  case  in  which  Red’s  only 
preventive  actions  are  interdicting  intermodal  infrastructure  and  convoys. 

a.  Model  Implementation 

This  variant  introduces  intermodal  infrastructure  and  convoy 
interdiction  to  the  model  functional  areas  and  processes  of  the  baseline  case  as 
described  in  Chapter  III,  Section  D. 

In  addition  to  the  probabilistic  and  deterministic  elements  already 
used.  Variant  I  adds  these  probabilistic  elements: 

1.  Red  interdiction  missions  arriving  at  an  exponential  rate. 

2.  Target  selection  following  a  uniform  distribution;  one  to  “decide” 
whether  to  destroy  an  infrastructure  or  a  convoy,  and  a  second  to  select  the 
individual  infrastructure  or  convoy.  In  the  case  of  convoy  selection,  a  third 
uniform  distribution  determines  how  many  of  the  units  are  destroyed. 

3.  An  adjustment  to  infrastructure  repair  times  following  a  truncated 
normal,  similar  to  the  consumption  adjustment  applied  in  Chapter  III,  Section 
D. 


This  variant  demonstrates  that  logistics  interdiction  slows  Blue’s 
advance,  either  by  constricting  logistics  flow  or  by  destroying  elements  of  that 
flow.  The  slowed  advance  should  be  evident  as  increased  site  capture  times  and 
events  in  which  Blue  is  stopped  alongside  the  highway  awaiting  resupply. 

b.  Results 

Three  hundred  model  runs  were  made  of  Variant  I.  Tables  5.4, 
5.5,  and  5.6  show  the  results,  in  the  same  order  as  Tables  5.1,  5,2  and  5.3.  The 
wider  confidence  intervals  and  higher  times  of  site  capture  in  Table  5.4  shows 
that  interdiction  did  delay  Blue.  The  table  also  shows  that  for  one  run,  Blue 
never  did  arrive  in  Plainview,  having  stalled  somewhere  between  Sweetwater 
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and  Lubbock,  before  the  model  run  was  stopped.  This  run  indicates  that  the 
model  allows  for  the  possibility  of  interdiction  being  so  severe  that  Blue  is  never 
resupplied. 


Location 

N 

Mean 

a 

StdDev 

Mn 

Max 

(Hours) 

(Hours) 

(Hours) 

(Hours) 

(Hours) 

Houston 

300 

0.0 

0 

0.0 

0.0 

0 

Abilene 

300 

19.1 

0 

0.0 

19.1 

19.1 

Sweetwater 

300 

47.6 

2.5 

5 

27.1 

197.4 

Lubbock 

299 

58.5 

3.6 

7.2 

31.7 

243.5 

Abernathy 

299 

86.9 

4.9 

9.8 

46 

265.8 

Plainview 

299 

114.8 

6.5 

13.0 

50.8 

195.8 

Table  5.4. 

Site 

capture  results  when  Red  interdicts  Blue. 

Note  the 

increased  maximum  capture  times  compared  to  Table  5.L. 

Commodity 

Day 

N 

Mean 

a 

StdDev 

Mn 

Max 

(STONS) 

(STONS) 

(STONS) 

(STONS) 

(STONS) 

Class  1:  Subsistence 

CRAT 

0 

300 

100000.0 

0.0 

0.0 

100000.0 

100000.0 

1 

300 

59867.3 

364.6 

1610.6 

55624.0 

64761.0 

2 

300 

42598.8 

3263.0 

14417.3 

24315.0 

63394.0 

3 

254 

17842.4 

3246.4 

13198.6 

0.0 

63214.0 

4 

122 

1.9021.1 

7489.2 

21102.2 

0.0 

62231.0 

5 

82 

19357.8 

8485.0 

19601.0 

0.0 

63717.0 

6 

54 

19984.8 

10535.4 

19749.8 

0.0 

62602.0 

7 

31 

9826.9 

7440.8 

10568.4 

0.0 

31555.0 

8 

19 

17712.9 

18026.8 

20045.2 

0.0 

60566.0 

9 

12 

9619.3 

18143.4 

16033.4 

0.0 

52398.0 

10 

4 

17908.2 

52672.8 

26873.9 

0.0 

56839.0 

11 

4 

9022.8 

20476.4 

10447.1 

0.0 

18991.0 

12 

4 

2937.5 

10410.6 

5311.5 

0.0 

10881.0 

13 

2 

108.0 

423.4 

152.7 

0.0 

216.0 

14 

2 

0.5 

2.0 

0.7 

0.0 

1.0 

15 

1 

2205.0 

0.0 

0.0 

2205.0 

2205.0 

1  Event 

Class  III:  POL 

Motor 

0 

300 

12000.0 

0.0 

0.0 

12000.0 

12000.0 

1 

300 

5892.8 

53.6 

236.4 

5124.0 

6681.0 

2 

299 

9541.7 

544.8 

2403.1 

4162.0 

11980.0 

3 

299 

8360.8 

429.2 

1893.4 

2809.0 

11668.0 

4 

299 

7425.7 

332.2 

1465.7 

2581.0 

11638.0 

5 

299 

6256.9 

303.8 

1340.4 

2585.0 

11024.0 

Table  5.5.  Status  of  Materiel  On  hand.  This  table  shows  the  amounts  of 
materiel  the  unit  reported  on  hand  for  each  day  (event)  of  usage. 
Ammunition  is  not  shown  since  combat  did  not  occur.  In  two  cases,  the 
objective  was  reached  on  the  13th  day.  One  case  Blue  never  arrived  at 
Lubbock. 
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The  effects  of  interdiction  on  logistics  seen  in  Table  5.5  are 
striking.  Blue  was  resupplied  at  a  slower  rate  than  the  baseline  case;  and  as 
indicated  by  the  zero  minimum  amounts  for  days  three  through  fourteen.  Blue 
had  no  subsistence  on  hand  for  some  rims.  A  comparison  of  the  mean  usage 
values  in  Table  5.6  shows  a  mosdy  declining  daily  subsistence  consumption, 
despite  a  constant  number  of  personnel.  In  other  words.  Blue  is  using  less 
because  Blue  has  less  to  use,  not  because  there  are  fewer  users.  Occasional 
spikes  in  this  subsistence  data  show  days  on  which  convoys  carrying  subsistence 
arrived.  In  the  baseline  case.  Blue’s  campaign  never  exceeded  four  days;  here. 


Commodity 

Day 

N 

Mean 

a 

StdDev 

Mn 

Max 

DOS 

(STONS) 

(STONS) 

(STONS) 

(STONS) 

(STONS) 

Class  L  Subsistence 

CRAT 

0 

300 

0.0 

0.0 

0.0 

0.0 

0.0 

NA 

1 

300 

40132.7 

364.6 

1610.6 

35239.0 

44376.0 

1.5 

2 

300 

40201.4 

356.0 

1572.6 

34909.0 

45531.0 

1.1 

3 

254 

38099.7 

1059.4 

4307.1 

24336.0 

44207.0 

0.5 

4 

122 

31767.6 

4428.0 

12477.0 

44.0 

44901.0 

0.6 

5 

82 

31130.9 

5953.6 

13752.9 

10.0 

43829.0 

0.6 

6 

54 

36464.4 

4672.6 

8759.2 

3.0 

43625.0 

0.5 

7 

31 

27765.0 

10409.0 

14784.5 

11.0 

41428.0 

0.4 

8 

19 

34043.1 

10313.0 

11467.6 

2.0 

42897.0 

0.5 

9 

12 

22974.1 

18718.2 

16541.2 

320 

42847.0 

0.4 

10 

4 

21192.5 

47867.0 

24421.9 

320 

42362.0 

0.8 

11 

4 

19597.8 

44356.8 

22631.0 

20 

39739.0 

0.5 

12 

4 

18714.2 

31838.4 

16244.1 

32.0 

39603.0 

0.2 

13 

2 

21250.0 

83166.8 

30004.0 

34.0 

42466.0 

0.0 

14 

2 

124.5 

358.6 

129.4 

33.0 

216.0 

0.0 

15 

1 

23371.0 

0.0 

0.0 

23371.0 

23371.0 

0.1 

Brent 

Class  III:  POL 

EOS 

Motor 

0 

300 

0.0 

0.0 

0.0 

0.0 

0.0 

NA 

1 

300 

6107.2 

53.6 

236.4 

5319.0 

6876.0 

1.0 

2 

299 

1189.5 

59.8 

263.6 

20.0 

1414.0 

8.0 

3 

299 

1563.8 

65.4 

288.9 

46.0 

1893.0 

5.3 

4 

299 

1559.0 

624 

275.0 

99.0 

1830.0 

4.8 

5 

299 

1561.9 

58.2 

256.3 

65.0 

1842.0 

4.0 

Figure  5.6.  Materiel  usage  during  interdiction. 

over  one  third  of  the  runs  exceeded  four  days.  The  data  for  subsistence  in  Table 
5.5  stops  at  the  point  where  resupply  essentially  ceased  to  arrive  at  the  division. 

c.  Model  Performance 

The  proposed  model  interdicts  intermodal  infrastructure  and 
convoys,  with  a  direct  impact  on  Blue’s  sustainability  as  measured  by  the 
MOE’s.  The  Diaries  in  Appendix  C  are  taken  from  the  300th  run  of  this  variant 
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and  show  supply  convoys  backing  up  in  Houston  for  several  days  after  the  roads 
from  Houston  were  interdicted.  The  Diary  shows  convoys  being  ambushed  and 
how  many  units  were  destroyed.  If  these  ambush  log  entries  are  compared  with 
the  Supply  Diary,  the  amount  of  materiel  lost  is  seen  as  a  new  supply 
requisition. 


The  model  expands  its  utility  as  a  planning  tool  by  showing 
potential  flow  botdenecks  resulting  from  interdiction,  potential  critical 
commodities  whose  failure  to  resupply  can  halt  the  advance,  and  the  potential 
volume  of  commodities  at  risk  by  interdiction.  These  indicators  can  help 
planners  place  intermediate  depots  and  preposition  those  items  likely  to  be  lost 
in  ambushes  but  critical  to  the  war  effort.  As  in  the  baseline  case,  the  model 
generated  data  provide  entry  arguments  for  planning  requirements  to  meet 
logistics  needs.  The  confidence  intervals  in  Tables  5.5  and  5.6  become 
increasingly  erratic  for  subsistence  as  the  campaign  continues  because  there  are 
fewer  instances  of  prolonged  campaigns  to  generate  them.  In  the  real  world 
sense,  this  is  comparable  to  a  campaign  likely  to  last  two  months,  but  could 
conceivably  last  six.  While  the  planner  cannot  use  confidence  intervals  based  on 
these  few  data  points,  the  mean  STONS  used,  coupled  with  the  minimum  and 
maximum  amounts  used,  can  still  provide  insights  to  the  logistics  requirements 
of  worst  case  campaign  outcomes  for  a  given  course  of  action. 

3.  Variant  2:  Blue  and  Red  Combat 

The  second  variant  allows  Red  to  fight  Blue  in  close  combat,  as  well  as  by 
intermodal  and  convoy  interdiction. 

a.  Model  Implementation 

This  second  variant  completes  the  functions  of  the  combat  module 
and  exercises  all  features  of  the  model  and  the  code.  No  new  probabilistic 
elements  are  added.  The  combat  module  calculates  materiel  consumption 
deterministically  as  a  function  of  the  number  of  firers,  the  rate  of  fire,  and  the 
duration  of  fire.  The  consumption  mechanism  does  continue  to  apply  the  usage 
adjustment  already  introduced  for  the  other  classes  of  aggregated  supply. 

This  variant  is  implemented  by  initializing  the  Red  forces.  Initially 
located  in  Plainview,  Red  will  move  south  until  it  detects  Blue.  A  single  battle  is 
fought  as  described  in  Chapter  III,  Section  F.  The  remnants  of  Blue  continue 
towards  Plainview  and  infrastructure  interdiction  is  also  enabled. 

The  model  shows  results  of  further  stressing  Blue’s  RSO&I  by 
adding  more  convoys  carrying  battle-expended  materials  to  the  logistics  flow. 
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The  time  of  the  battle  will  vary  somewhat  since  both  sides  experience  random 
travel  delays  as  they  pass  through  sites  enroute  towards  each  other. 

b.  Results 

Tables  5.7,  5.8  and  5.9  show  the  results  of  three  hundred  runs  in 
which  Red  fought  Blue  and  interdicted  his  lines  of  communication.  As  in  the 
first  variant,  the  mean  arrival  times  for  this  variant  were  longer  than  the 
baseline  case,  showing  that  Blue  experienced  campaign  delays  caused  by  both 
infrastructure  and  convoy  interdiction  and  by  combat 


Location 

N 

Mean 

Cl 

StdDev 

Mn 

Max 

(Hours) 

(Hours) 

(Hours) 

(Hours) 

(Hours) 

Houston 

300 

0 

0.0 

0.0 

0 

0 

Abilene 

300 

19.1 

0.0 

0.0 

19.1 

19.1 

Sw  eetw  ater 

283 

44.7 

4.8 

20.9 

23.1 

300.2 

Lubbock 

277 

58.3 

7.0 

29.4 

30.9 

320.8 

Abernathy 

249 

81.6 

11.2 

44.9 

40.8 

421.9 

Plainview 

283 

104.3 

15.0 

60.2 

42.5 

300.2 

Table  5.7.  Site  capture  results  when  Red  fights  Blue  and  interdicts  his  lines  of 
communication. 


Tables  5.8  and  5.9  show  that  Blue  experienced  many  subsistence 
shortages,  considering  that  fully  stocked  Blue  would  use  about  40000  rations 
daily.  As  in  the  first  variant,  POL  levels  remained  high  due  to  the  small  fuel 
depot  in  Abilene.  The  effects  of  combat  with  Red  are  seen  from  Tables  5.8  and 
5.9.  While  Red’s  status  is  not  shown,  it  is  dear  that  Blue  could  not  fight 
another  battle  of  the  same  magnitude  without  resupply. 

c.  Model  Performance 

The  mean  site  arrival  times  in  this  variant  are  lower  than  those  of 
the  first  variant;  a  manifestation  of  interrupting  a  wait  state.  In  many  of  the 
runs.  Blue  was  conducting  an  imposed  wait,  or  site  delay,  in  Sweetwater  when 
contact  with  Red,  moving  from  Lubbock  to  Sweetwater,  occurred. 

The  model  generated  attrition  values  using  the  algorithms  in 
Chapter  III,  Section  F.  These  values  are  reflected  as  the  Class  VII  usage  data  in 
Tables  5.9.  These  numbers  give  approximations  of  materiel  lost  to  combat;  a 
calculation  difficult  for  the  military  planners  because  of  the  variability  involved: 
will  battle  occur?  where?  how  much  will  be  expended?,  etc.  While  Table  5.9  is 
not  necessarily  predictive,  it  does  provide  the  military  planner  with  estimates  for 
planning  RSO&I  to  replace  materiel  lost  in  combat. 
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These  three  case  demonstrations  show  that  the  proposed  model  simulates 
events  in  which  the  more  Blue’s  lines  of  communication  are  stressed,  the  worse 
off  Blue  is  and  a  longer  campaign  results.  The  confidence  intervals  and  the 
MOE’s  provide  useful  indicators  of  Blue’s  logistic  health.  These  demonstrations 
show  that  the  model  does  quantify  on  hand  amounts  and  usage  as  the  campaign 
progresses.  The  confidence  intervals  and  means  provide  useful  numbers  for  the 
military  planner,  either  as  likely  ranges  of  materiel  available  for  events  with  a 

large  number  of  data  points,  or  as  approximations  for  those  with  a  small 
number. 


Commodity  Day 

N 

Mean 

a 

StdDev 

Mn 

Max 

(STONS) 

(STONS) 

(STONS) 

(STONS) 

(STONS) 

Class  1:  Subsistence 

CRAT  0 

300 

100000.0 

0 

0.0 

100000.0 

100000 

1 

300 

59935.0 

385.8 

1705.0 

54024.0 

64659 

2 

300 

45805.5 

3557 

15716.7 

24282.0 

72298 

3 

258 

25022.5 

3715.4 

15224.2 

0.0 

67130 

4 

134 

17392.6 

6480 

19135.8 

0.0 

68477 

5 

70 

8291.1 

7205.8 

15379.6 

0.0 

65699 

6 

40 

3835.0 

5727.6 

9240.9 

0.0 

41445 

7 

27 

5029.9 

9159.2 

12141.0 

0.0 

51404 

8 

18 

600.6 

1236.2 

1337.9 

0.0 

5418 

9 

7 

17.3 

38 

25.7 

0.0 

72 

10 

5 

10919.6 

42451 

24215.1 

0.0 

54236 

11 

4 

3825.5 

14486.2 

7390.9 

0.0 

14911 

12 

4 

322 

111.2 

56.8 

0.0 

117 

13 

4 

665.2 

2118 

1080.7 

0.0 

2266 

14 

3 

8.7 

34 

15.0 

0.0 

26 

15 

2 

64.0 

250.8 

90.5 

0.0 

128 

16 

2 

0.0 

0 

0.0 

0.0 

0 

17 

2 

0.0 

0 

0.0 

0.0 

0 

18 

2 

129.0 

70.6 

25.5 

111.0 

147 

19 

1 

0.0 

0 

0.0 

0.0 

0 

20 

1 

35.0 

0 

0.0 

35.0 

35 

21 

1 

1024.0 

0 

0.0 

1024.0 

1024 

Event 

Class  lit  POL 

Motor  0 

300 

12000.0 

0 

0.0 

12000.0 

12000 

1 

300 

5892.2 

57.8 

255.5 

5000.0 

6585 

2 

283 

9354.3 

592.2 

2541.0 

4128.0 

11986 

3 

277 

9135.9 

452.8 

1922.1 

2945.0 

11670 

4 

249 

8229.0 

417.6 

1681.2 

1215.0 

11302 

5 

218 

7082.4 

340.4 

1281.8 

1232.0 

.10407 

Table  5.8.  Status  of  materiel  on  hand  when  Red  fights  Blue  and 
interdicts  his  lines  of  communication. 
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Commodity 

brent 

N 

Mean 

Cl 

StdDev 

Mn 

Max 

(STONS) 

(STONS) 

(STONS) 

(STONS) 

(STONS) 

Class  V:  Ammunition 

LAAW 

0 

300 

1000 

0 

0.0 

1000 

1000 

1 

296 

0 

0 

0.0 

0 

0 

BOMB 

0 

300 

6000 

0 

0.0 

6000 

6000 

1 

296 

2658.1 

32.2 

141.0 

2288 

3094 

HELLRR 

0 

300 

400 

0 

0.0 

400 

400 

1 

296 

0 

0 

0.0 

0 

0 

AIM9 

0 

300 

50 

0 

0.0 

50 

50 

1 

296 

0 

0 

0.0 

0 

0 

NATO 

0 

300 

0 

0 

0.0 

0.02 

0 

1 

296 

0 

0 

0.0 

0 

0 

HE-1 

0 

300 

400 

0 

0.0 

400 

400 

1 

296 

0 

0 

0.0 

0 

0 

PD-1 

0 

300 

50 

0 

0.0 

50 

50 

1 

296 

0 

0 

0.0 

0 

0 

HE-2 

0 

300 

0 

0 

0.0 

0.02 

0 

1 

296 

3470.3 

142.4 

625.3 

1906.02 

5569 

PD-2 

0 

300 

400 

0 

0.0 

400 

400 

1 

296 

0 

0 

0.0 

0 

0 

Class  VII:  Major 

MBT 

0 

300 

256 

0 

0.0 

Zoo 

256 

1 

296 

93.3 

1.4 

6.2 

69 

113 

INF 

0 

300 

17000 

0 

0.0 

17000 

17000 

1 

296 

9779.5 

68 

298.4 

9040 

10703 

CAS 

0 

300 

72 

0 

0.0 

72 

72 

1 

296 

70 

0 

0.0 

70 

70 

Arty 

0 

300 

267 

0 

0.0 

267 

267 

1 

296 

230.2 

0.4 

1.6 

226 

234 

Figure  5.8  (Continued).  Status  of  materiel  on  hand  when  Red  fights  Blue 
and  interdicts  his  lines  of  communication. 
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Commodity  Day 


CRAT 


Motor 


0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 

E^ent 

0 

1 

2 

3 

4 

5 


300 

300 

300 

258 

134 

70 

40 

27 

18 

7 

5 

4 

4 

4 

3 

2 

2 

2 

2 

1 

1 

1 

300 

300 

283 

277 

249 

218 


Mean 
(STONS) 
ass  i:  Subs  is  te 
0.0 

40065.0 

36548.9 

32569.0 

28392.4 

21699.8 

16478.7 

17265.9 

11085.4 
4193.3 

11071.8 

19197.5 

4561.5 

9508.2 

5903.3 
13113.0 
8003.0 
14795.0 
18276.0 

147.0 
1044.0 
21978.0 
Class  ni:  POL 
0.0 

6107.8 
1153.2 

825.8 

1517.8 
1589.7 


Cl 

StdDev 

Mn 

Max 

DOS 

(STONS) 

nee 

(STONS) 

(STONS) 

(STONS) 

0 

0.0 

0.0 

0.0 

NA 

385.8 

1705.0 

35341.0 

45976.0 

1.5 

849.6 

3753.9 

26457.0 

45728.0 

1.3 

921.8 

3776.9 

25145.0 

44380.0 

0.8 

3216.6 

9498.4 

310.0 

41947.0 

0.6 

6533.8 

13945.4 

2.0 

39122.0 

0.4 

8874.8 

14318.8 

21.0 

42398.0 

0.2 

11943.8 

15832.1 

1.0 

40877.0 

0.3 

13258.8 

14350.2 

1.0 

40834.0 

0.1 

13508 

9117.0 

82.0 

24737.0 

0.0 

29569 

16866.9 

1.0 

40459.0 

1.0 

40769.8 

20800.9 

864.0 

40550.0 

0.2 

13745.4 

7012.9 

176.0 

14899.0 

0.0 

21597.6 

11019.2 

117.0 

23089.0 

0.1 

22073.4 

9753.2 

199.0 

17165.0 

0.0 

24355 

8786.5 

6900.0 

19326.0 

0.0 

16628.6 

5999.1 

3761.0 

12245.0 

0.0 

15668.2 

5652.6 

10798.0 

18792.0 

0.0 

18388.8 

6634.1 

13585.0 

22967.0 

0.0 

0 

0.0 

147.0 

147.0 

0.0 

0 

0.0 

1044.0 

1044.0 

0.0 

0 

0.0 

21978.0 

21978.0 

0.0 

EOS 

0 

0.0 

0.0 

0.0 

NA 

57.8 

255.5 

5415.0 

7000.0 

1.0 

74.8 

320.9 

14.0 

1432.0 

8.1 

124.8 

529.5 

39.0 

1792.0 

11.1 

822 

331,1 

210.0 

1816.0 

5.4 

57.2 

215.6 

58.0 

1865.0 

4.5 

Table  5.9.  Event  usage  when  Red  fights  Blue  and  interdicts  his  lines  of 
communication. 
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Commodity  Event 

N  Mean  Cl 

(STONS)  (STONS) 

Class  V:  Ammunition 

StdDev 

(STONS) 

Min 

(STONS) 

Max 

(STONS) 

EOS 

LAAW 

0 

300 

0.0 

0 

0.0 

0.0 

0.0 

NA 

1 

296 

1000.0 

0 

0.0 

1000.0 

1000.0 

0.0 

BOMB 

0 

300 

0.0 

0 

0.0 

0.0 

0.0 

NA 

1 

296 

3341.9 

322 

141.0 

2906.0 

3712.0 

0.8 

HELLFIR 

0 

300 

0.0 

0 

0.0 

0.0 

0.0 

NA 

1 

296 

400.0 

0 

0.0 

400.0 

400.0 

0.0 

AIM9 

0 

300 

0.0 

0 

0.0 

0.0 

0.0 

NA 

1 

296 

50.0 

0 

0.0 

50.0 

50.0 

0.0 

NATO 

0 

300 

0.0 

0 

0.0 

0.0 

0.0 

NA 

1 

296 

0.0 

0 

0.0 

0.0 

0.0 

NA 

HE-1 

0 

300 

0.0 

0 

0.0 

0.0 

0 

NA 

1 

296 

400.0 

0 

0.0 

400.0 

400.0 

0.0 

PD-1 

0 

300 

0.0 

0 

0.0 

0.0 

0.0 

NA 

1 

296 

50.0 

0 

0.0 

50.0 

50.0 

0.0 

HE-2 

0 

300 

0.0 

0 

0.0 

0.0 

0.0 

NA 

1 

296 

16529.7 

142.4 

625.3 

14431.0 

18094.0 

0.2 

PD-2 

0 

300 

0.0 

0 

0.0 

0.0 

0.0 

NA 

1 

296 

400.0 

Class  VI!:  Major 

0 

0.0 

400.0 

400.0 

0.0 

MBT 

0 

300 

0.0 

0 

0.0 

0.0 

0.0 

NA 

1 

296 

162.7 

1.4 

6.2 

143.0 

187.0 

1.6 

INF 

0 

300 

0.0 

0 

0.0 

0.0 

0.0 

NA 

1 

296 

7220.5 

68 

298.4 

6297.0 

7960.0 

2.4 

CAS 

0 

300 

0.0 

0 

0.0 

0.0 

0.0 

NA 

1 

296 

2.0 

0 

0.0 

2.0 

2.0 

36.0 

Arty 

0 

300 

0.0 

0 

0.0 

0.0 

0.0 

NA 

1 

296 

36.8 

0.4 

1.6 

33.0 

41.0 

7.3 

Table  5*9  (Continued).  Event  usage  when  Red  fights  Blue  and  interdicts  his  lines  of 
communication. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


This  thesis  has  developed  a  logistics  flow  model  as  a  campaign  planning 
tool  to  fill  the  gaps  of  investigating  the  effects  of  logistics  on  ground  combat  and 
maneuver  arising  from  a  general  lack  of  logistics  planning  aids  in  modern 
combat  models.  Although  the  model  may  be  implemented  in  any 
object-oriented  programming  language,  MODSIM  was  used  in  this  thesis 
because  of  its  useful  variety  of  built-in  data  structures  and  event-based  program 
execution  abilities. 

Demonstrations  of  the  model  that  showcased  the  different  functional 
areas  showed  that  the  ground  campaign  suffered  logistically  when  RSO&I  was 
stressed  through  decreased  flow  due  to  interdiction  and  increased  demand  for 
replacing  items  destroyed  in  combat.  The  model  outputs  include  95% 
confidence  intervals  for  the  amounts  of  commodities  used  during  the  campaign. 
These  intervals  can  provide  military  planners  with  insights  into  a  plan’s  logistics 
flow  when  they  are  compared  with  those  from  alternative  courses  of  action.  The 
contribution  to  campaign  planning  is  a  tool  that  measures  a  force’s 
sustainability  in  Days  of  Supply  and  Events  of  Supply,  derived  from  combat 
specific  consumption  mechanisms,  to  help  determine  the  feasibility  of  a 
potential  course  of  action. 

The  basic  model  described  in  Chapter  III  uses  several  sophisticated 
techniques  to  view  theater  level  logistics  flow.  It  has  the  ability  to  flow  materiel 
using  many  transportation  modes  like  rail,  air,  boat  and  barge.  Joint  Logistics 
Over  the  Shore,  and  others.  The  map  network  extends  itself  to  multiple  lines  of 
advance  in  different  directions.  The  detection  sub-model  of  the  combat  model 
eases  the  transition  to  event-flow  programming  by  determining  in  advance  when 
events  will  occur  so  that  alternative  time-step  methods  are  not  required.  The 
attrition  sub-model  of  the  combat  model  is  a  standard  model  used  throughout 
the  military  modeling  and  campaign  planning  communities.  An  object-oriented 
and  modular  design  allows  portions  of  the  model  to  be  further  refined  as  long  as 
the  interfaces  are  maintained  correctly.  This  allows  the  model  to  adapt  to  future 
needs. 


Several  enhancements  to  the  model  could  improve  its  utility  for  campaign 
support: 

1.  An  intermodal  throughput  capacity  should  be  completed. 
Currently,  the  data  structure  stores  the  throughput  capacities  of  arc,  terminals, 
and  sites.  However,  they  are  not  implemented  in  the  model  because  a 
satisfactory  throughput  model  was  not  found.  Rather  than  using  the  current 
throughput  capacity  as  an  absolute  upper  bound  on  flow  for  an  interval,  a  more 
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desirable  model  would  consider  travel  time  as  a  function  of  congestion  and  slow 
flow  appropriately.  Since  congestion  is  an  instantaneous  function,  the  event 
flow  approach  has  difficulties  unless  travel  time  for  all  traffic  on  an  arc  is 
recomputed  each  time  any  traffic  element  does  something  that  could  alter 
congestion. 

2.  Encode  the  ability  to  flow  troops  and  materiel  on  more  than  one 
axis  of  advance.  Encoding  this  requires  adding  algorithms  like  Djikstra's 
algorithm  to  determine  which  arcs  should  be  used  to  route  logistics  flow. 

3.  The  program  currently  moves  materiel  only  by  road,  even  though 
both  the  model  and  the  encoded  data  structure  support  numerous  other  modes 
of  transportation.  Completing  this  capability  will  require  algorithms  that 
prioritize  among  the  various  transports  and  determine  which  intermodal  means 
a  shipment  will  use.  This  feature  should  also  include  a  Djikstra’s  algorithm  to 
help  determine  which  intermodal  means  is  best. 

This  proposed  model  identifies  and  uses  many  basic  concepts  and 
methodologies  to  produce  a  suitable  logistics  analysis  tool  for  military  planners 
to  use  when  comparing  competing  courses  of  action  to  support  and  develop  a 
campaign  plan.  This  model  is  also  a  springboard  for  more  complex  approaches 
to  simulate  and  model  the  effects  of  logistics  on  ground  combat  and  maneuver. 
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APPENDIX  A.  MAPPING  THE  MODEL 


The  goal  of  the  model  mapping  is  to  make  it  visually  understandable  with 
a  few  uncomplicated  rules.  It  is  intended  to  dovetail  with  object-oriented 
languages  supporting  synchronous  and  asynchronous  events,  modules, 
user-enumerated  types,  and  canceling  events.  Three  basic  concepts  guide  the 
process: 

1.  The  data  structure  map  and  the  process  flow  maps  are  separate.  The 
data  structure  map  is  the  basic  road  map  for  the  model.  It  shows  data 
substructure  ownership  and  visibility,  and  where  specific  elements  of  data 
reside.  Only  the  fields  of  the  data  structure  are  shown  on  the  data  structure 
map.  The  process  flow  maps  show  how  the  data  structure  is  manipulated  to 
execute  the  model.  Ideally,  the  form,  or  data  structure,  facilitates  the  function, 
or  process  flow. 

The  model  is  a  collection  of  processes  operating  together  to 
accomplish  a  goal.  Each  process  flow  map  shows  only  those  functions  that 
support  that  process.  The  set  of  process  maps  comprises  the  whole  of  the 
model  flow.  Completed,  the  model  map  set  will  have  one  data  structure  map 
and  as  many  process  flow  maps  as  necessary. 

2.  Colors  broadly  identify  form  and  function  classes  and  elements. 
Table  A.l  shows  the  colors  assigned  to  the  various  forms  and  functions  of  the 
model.  Only  a  few  colors  are  used  since  they  are  not  intended  to  show  subtle 
nuances  of  model  construction. 

3.  A  few  different  types  of  shapes  and  arrows  are  used.  Circles  are 
used  as  connectors  for  records,  list  of  passed  parameters,  and  page  breaks. 
Ovals  are  used  as  connectors  for  synchronous  and  asynchronous  procedures. 
Procedures  are  gathered  together  into  rectangles.  If  a  process  map  uses 
procedures  from  different  modules,  then  the  procedures  are  drawn  together  and 
bound  freehand  to  help  show  modular  interaction.  Form  connectors, 
particularly  for  fields,  records,  and  user-enumerated  types  are  labeled 
alphabetically.  Function  connectors  are  labeled  in  module.object.method 
shorthand.  For  instance,  a  connector  to  a  method  of  DepotManagerObject 
called  FillRequisition,  found  in  the  module  Logistics,  might  be  L.DMO.FR  if  the 
connector  crosses  module  boundaries  or  pages,  and  DMO.FR  within  module  and 
page  boundaries. 
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dotted  line 

Composition,  or  group,  elements  (form) 

dash-dot-dash  line 

Fields  (form) 

solid  line 

Everything  else  (form  and  function) 

Blue 

Process  flow  inside  a  function 

Green 

Object  (inheritance,  field,  erouo) 

Dark  Red 

Asynchronous  flow 

Light  Red 

[  Synchronous  flow 

Yellow 

Modules 

Blue 

Fields,  records,  user-enumerated  tvoes 

Lavender 

Canceling  edges 

Black 

Header  information  and  labels 

Table  A.  1 .  Visual  aid  assignments 

Arrows  point  in  the  direction  of  increasing  hierarchy  in  form,  and  flow  in 
function.  Passed  parameters  are  shown  with  the  line.  If  the  passed  parameters 
are  legion,  then  a  parameter  connecting  circle  is  used.  Table  A.1  shows  how 

colors  and  shapes  are  used  together  to  express  the  data  structure  and  process 
flow  maps.  r 


For  instance,  anything  associated  with  an  object  is  green.  The  data 
structure  would  use  a  green  solid  line  to  show  that  an  object  inherits  from 
another  with  an  arrow  pointing  from  child  to  parent  (“is-a”  relationship).  In  a 
case  in  which  one  object  forms  a  field  for  another  object,  a  green  dash-dot-dash 
line  points  from  the  field-provider  object  to  the  field-user  object  (“has  a” 
relationship).  The  color  showing  the  clearest  depiction  is  used  whenever  several 
different  colors  might  be  used. 

For  example,  refer  to  Figure  B.6  in  Appendix  B.  The  figure  shows  one 
element  of  data  structure,  the  RefereeObj,  and  two  processes:  Oracle  and 
Intervene.  The  map  of  the  RefereeObj  shows  that  this  object  uses  eight  other 
objects  as  fields,  depicted  by  the  dot-dash-dot  green  lines  from  the  field  object 
connectors  to  the  RefereeObj.  If  RefereeObj  had  used  any  user-enumerated 
types  or  records,  these  would  have  been  listed  in  blue. 

The  synchronous,  or  sequential,  Oracle  method  is  shown  in  light  red.  An 
asynchronous,  or  simultaneous,  method  might  be  invoked  from  within  Oracle. 
This  method,  GoDormant,  is  shown  in  dark  red.  Process  flow  inside  Oracle  is  in 
blue,  and  orders  to  follow  on  sequential  methods  are  red,  with  arrows  carrying 
passed  parameters  to  the  method  connector.  Intervene  uses  canceling  events,  as 
shown  in  lavender.  These  events  are  used  whenever  the  RefereeObj  must 
interrupt  a  MovingObj’s  activity.  If  the  canceling  event  for  MO.Move  is 
followed  to  the  actual  object  interrupted,  it  interrupts  CF.Move.  This  event  is 

APPendix  B>  FiSure  B-5-  Note  that  the  interrupting  method  connector, 
RO.IVN,  is  shown  in  dark  red  since  it  is  an  asynchronous  event.  Since  it  is  also 
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an  interrupting  event,  it  might  also  be  shown  in  lavender.  This  is  a  case  when 
different  coloring  might  be  used  for  the  same  event.  Which  one  is  used  depends 
upon  clarity  and  preference. 

An  example  of  modular  grouping  is  shown  in  Appendix  B,  Figure  B.2, 
which  shows  the  data  structure  for  MovingObj.  The  figure  shows  that 
MovingObj  draws  from  four  modules:  MovingObj,  Logistics  1,  OrderOfBattle, 
and  BattleData. 
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APPENDIX  B.  MODEL  MAP  PORTFOLIO 

Appendix  A  describes  how  the  model  is  mapped  during  the  transition 
from  concept  and  event  diagrams  to  object  oriented  depiction  in  preparation  for 
coding.  This  Appendix  contains  the  data  structure  map  and  the  various  process 
flow  maps  used  to  implement  the  model.  They  represent  the  bridge  between 
Chapter  Ill’s  description  of  the  model  and  Chapter  IV’s  implementation  in 
MODSIM. 

Instead  of  dispersing  the  various  figures  throughout  the  body  of  the 
thesis,  they  are  gathered  in  this  Appendix  to  help  visual  understanding.  The 
connectors  are  unique  and  refer  to  the  same  objects  throughout  the  diagrams. 
The  syntax  of  the  diagrams  is  described  in  Appendix  A. 

These  abbreviations  are  used  in  the  portfolio: 

SO  ShellObj 

RO  RefereeObj 

MO  MovingObj 

F  Force 

UT  UnitType 

CF  CombatForce 

OP  OpForce 

E  Engineer 

DMO  DepotManagerObj 

TO  TransportObj 

LPFO  LogisticsPlanningFactorsObj 

FT  FileTracker 

UO  UncertainObj 
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BBT  reeObj[ANYOB  J 


85 

uisjsXs  30 dap  pure  deni  9ip  jo  deui  sjnprujs  bjbq  T9 


/ 

1 

/ 


ir  a)  <  < 

H  5-LU  LU 
0'S 

%f.  §>  ®  K 

w  q.  8  —  oc 
D  h-  h-  O  H 


WpnType: 
WeaponType 
Number:  REAL 
PSI, 

AmmoType 

Pssk 


^  UnitType 

WeaponsLSst:  WeaponObj 


Figure  B*2.  Data  structure  map  showing  MovingObj  and  descendent 
architecture 
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RunNumber:  INTEGER 

\  /  EnabIed:BOOLEAN 


Unit:  STRING 

SiteLog:  ARRAY  INTEGER  OF  StatObj 
Album:  ARRAY  SplyClassType  OF  BasicGroupObj 


Unit  Recorder:  RecorderObj 
ShellFlow:  FileTracker 
FingerOfChace:  UncertainObj 


InitialOnhand:  REAL 

NounName:  STRING 

Snapshots, 

CurrentSnapshot 

Usage 

CurrentUsage:  Stats 


Stats 

Time 

Sum 

SumOfSquares 

Mean 

Min 

Max:  REAL 
N:  INTEGER 
Next:  Stats 


0 


Figure  B.3.  Data  structure  map  showing  the  data  collection  shell  and 
RefereeObj 
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(  LLO.CCC  ) 

(3) 


1  LLO.ConsumeCommoditvBvCIass  ^ 


Foreach  IARO  in  DatafAnySCT] 
Rate - 


© 


ElapsedTime:=SimTime-TimeStamp  j 
Expended  :=Rate*ElapsedTime*.—. 

AnyMO. Number  (Jy 

Consume  Commodity - 


fK  LPFO.GLPF  y 


TimeStamp.-SimTime 


♦C  LLO.CCT 


(  LLO.CC 


LLO.ConsumeCommoditv 
MylARO 


^<:;[ARaGiARO';> 
DecOnhandAmount  -^Realc;jARaDOA'.:> 
SendRequisition 

LogUseage - - ►c'FT.LCQ© 


IARO.GIARO 


(s) 


InvAndReqObi.GetlARO 

Use  input  parameters  to 
find  InvAndReqObj.  Error 
if  no  match 


© 


IARO.  DecOnhandAmount 

Decrease  OnhandAmount 
by  input  integer 


LPFO.GLPF 


© 


LPFQ.GetLoqistics 
PlanningFactors 
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Parameters 
AnySCT ;  SCT 
AnyNounName:  STRING 
AnyAmount:  REAL 
AnyUser:  MOType 
AnyDepotMgr:  DMO 


Parameters 
AnyUser:  MOType 
AnyNounName:  STRING 
AnyReal:  REAL 


Parameters 

AnyMovIngObject:  MovingObj 
AnyRefereeObj:  RefereeObj 
AnyUseageRate:  STRING 


Parameters 

ItemNounName:  STRING 
ItemType:  SCT 
UserMOType:  MOType 
AnyUseageRate:  STRING 


Parameters 

AnySCT:  SCT 
AnyNounName:  STRING 


Figure  B.4.  Commodity  consumption  process  flow 
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Figure  B.5.  POL  Consumption  process  flow 
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WarDiary:  FileTracker 
FingerOfChance:  UncertainObj 


Figure  B.6.  The  Referee  and  its  Orade  and  Intervention  processes. 
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APPENDIX  C  DIARY  EXAMPLES 


This  Appendix  gives  the  War  and  Supply  Diaries  for  a  single  run  of  the 
model.  These  particular  Diaries  are  taken  from  the  last  rim  of  Variant  1:  Red 
Interdiction,  as  described  in  Chapter  V,  Section  C. 

1.  WAR  DIARY 

War  Diary 
Diary  for  Run  300 

0.00  Houston  captured 

0.00  Houston  depot  made  operational 

0.00  IDiv  leaving  Houston  and  moving  to  Abilenel91.0  miles  away. 

14.77  Houston's  road  facility  interdicted. 

19. 10  IDiv  arrived  at  Abilene 

19.10  Abilene  captured 

19.10  Abilene  depot  made  operational 

19.10  IDiv  started  a  23.5  hour  delay  in  transit  at  Abilene 

19.10  Convoyl  started  a  3.5  hour  delay  in  transit  at  Houston 
22.57  Convoyl  started  a  3.9  hour  delay  in  transit  at  Houston 
24.00  Convoy2  started  a  4.5  hour  delay  in  transit  at  Houston 
26.43  Convoyl  started  a  5.5  hour  delay  in  transit  at  Houston 
28.51  Convoy2  started  a  4.8  hour  delay  in  transit  at  Houston 
31.97  Convoyl  started  a  5.9  hour  delay  in  transit  at  Houston 
33.31  Convoy2  started  a  5.2  hour  delay  in  transit  at  Houston 
37.83  Convoyl  started  a  5.5  hour  delay  in  transit  at  Houston 
38.56  Convoy2  started  a  5.5  hour  delay  in  transit  at  Houston 

42.63  IDiv  leaving  Abilene  and  moving  to  Sweetwater  40.0  miles  away. 

43.37  Convoyl  started  a  1.9  hour  delay  in  transit  at  Houston 

44.02  Convoy2  started  a  3.9  hour  delay  in  transit  at  Houston 

44.27  Convoy2  was  ambushed.  24  units  destroyed,  5  units  remaining. 

44.27  Convoy2  started  a  19.1  hour  delay  in  transit  at  Houston 

44.27  Convoy3  started  a  5.2  hour  delay  in  transit  at  Houston 
45.26  Convoyl  started  a  5.5  hour  delay  in  transit  at  Houston 

46.63  IDiv  arrived  at  Sweetwater 

46.63  Sweetwater  captured 

46.63  IDiv  started  a  25.5  hour  delay  in  transit  at  Sweetwater 

46.63  Convoy4  leaving  Abilene  and  moving  to  Sweetwater  40.0  miles  away. 
48.00  Convoy5  started  a  4.2  hour  delay  in  transit  at  Houston 
49.13  Convoy4  is  resupplying  IDiv 

49.13  IDiv  leaving  Sweetwater  and  moving  to  Lubbock  51.0  miles  away. 
49.48  Convoy3  started  a  4.7  hour  delay  in  transit  at  Houston 

50.77  Convoyl  started  a  4.4  hour  delay  in  transit  at  Houston 


51.67  IDiv  arrived  at  Lubbock 

51.67  Lubbock  captured 

51.67  Lubbock  depot  made  operational 

51.67  IDiv  started  a  30.6  hour  delay  in  transit  at  Lubbock 

51.67  Convoy6  leaving  Abilene  and  moving  to  Sweetwater  40.0  miles  away. 

52.15  Convoy5  started  a  5.2  hour  delay  in  transit  at  Houston 
54.19  Convoy3  started  a  5.4  hour  delay  in  transit  at  Houston 
55.17  Convoy  1  started  a  5.0  hour  delay  in  transit  at  Houston 

55.67  Convoy6  arrived  at  Sweetwater 

55.67  Convoy6  started  a  4.0  hour  delay  in  transit  at  Sweetwater 

57.32  Convoy5  started  a  5.4  hour  delay  in  transit  at  Houston 

59.57  Convoy3  started  a  6.3  hour  delay  in  transit  at  Houston 

59.67  Convoy6  leaving  Sweetwater  and  moving  to  Lubbock  5 1.0  miles 
away. 

60.15  Convoy  1  started  a  3.4  hour  delay  in  transit  at  Houston 
62.07  Convoy6  is  resupplying  IDiv 

62.07  IDiv  leaving  Lubbock  and  moving  to  Abernathy  51.0  miles  away. 
62.74  Convoy5  started  a  3.3  hour  delay  in  transit  at  Houston 
63.38  Convoy2  started  a  5.0  hour  delay  in  transit  at  Houston 

63.57  Convoy  1  started  a  2.4  hour  delay  in  transit  at  Houston 

64.62  IDiv  arrived  at  Abernathy 

64.62  Abernathy  captured 

64.62  IDiv  started  a  21.2  hour  delay  in  transit  at  Abernathy 

64.62  Convoy 7  leaving  Lubbock  and  moving  to  Abernathy  51.0  miles  away. 
65.85  Convoy3  started  a  4.1  hour  delay  in  transit  at  Houston 

65.94  Convoy  1  started  a  4.4  hour  delay  in  transit  at  Houston 
66.00  Convoy5  started  a  3.9  hour  delay  in  transit  at  Houston 
67.02  Convoy 7  is  resupplying  IDiv 

67.02  IDiv  leaving  Abernathy  and  moving  to  Plainview  51.0  miles  away. 

68.33  Convoy2  started  a  4.5  hour  delay  in  transit  at  Houston 

69.57  IDiv  arrived  at  Plainview 

69.57  Plainview  captured 

69.57  Convoy8  leaving  Lubbock  and  moving  to  Abernathy  51.0  miles  away. 

69.92  Convoy5  started  a  4.9  hour  delay  in  transit  at  Houston 

69.93  Convoy3  started  a  4.1  hour  delay  in  transit  at  Houston 

70.33  Convoy  1  started  a  4.3  hour  delay  in  transit  at  Houston 
72.87  Convoy2  started  a  4.7  hour  delay  in  transit  at  Houston 
72.97  Convoy8  arrived  at  Abernathy 

72.97  Convoy8  started  a  4.7  hour  delay  in  transit  at  Abernathy 
74.07  Convoy3  started  a  4.1  hour  delay  in  transit  at  Houston 

74.62  Convoy  1  started  a  4.7  hour  delay  in  transit  at  Houston 
74.78  Convoy5  started  a  4.7  hour  delay  in  transit  at  Houston 
77.59  Convoy2  started  a  2.8  hour  delay  in  transit  at  Houston 
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77.62  Convoy8  leaving  Abernathy  and  moving  to  Plainview  51.0  miles 
away. 

78.12  Convoy3  started  a  4.5  hour  delay  in  transit  at  Houston 

79.33  Convoyl  started  a  5.2  hour  delay  in  transit  at  Houston 
79.51  ConvoyS  started  a  4.2  hour  delay  in  transit  at  Houston 

80.39  Convoy2  started  a  4.6  hour  delay  in  transit  at  Houston 
81.02  Convoy8  arrived  at  Plainview 

82.60  Convoy3  started  a  3.1  hour  delay  in  transit  at  Houston 
83.70  Convoy5  started  a  2.7  hour  delay  in  transit  at  Houston 

84.57  Convoyl  started  a  3.2  hour  delay  in  transit  at  Houston 
85.01  Convoy2  started  a  3.5  hour  delay  in  transit  at  Houston 

85.72  Convoy3  started  a  4.0  hour  delay  in  transit  at  Houston 

86.39  Convoy5  started  a  4.2  hour  delay  in  transit  at  Houston 

87.73  Convoyl  started  a  3.4  hour  delay  in  transit  at  Houston 
88.47  Convoy2  started  a  4.8  hour  delay  in  transit  at  Houston 
89.69  Convoy3  started  a  3.3  hour  delay  in  transit  at  Houston 

90.57  Convoy5  started  a  3.3  hour  delay  in  transit  at  Houston 
91.14  Convoyl  started  a  5.3  hour  delay  in  transit  at  Houston 
92.96  Convoy3  started  a  5.6  hour  delay  in  transit  at  Houston 
93.24  Convoy2  started  a  4.4  hour  delay  in  transit  at  Houston 
93.86  Convoy5  started  a  2.6  hour  delay  in  transit  at  Houston 

96.42  Convoyl  started  a  5.6  hour  delay  in  transit  at  Houston 

96.43  Convoy5  started  a  3.8  hour  delay  in  transit  at  Houston 
97.65  Convoy2  started  a  4.7  hour  delay  in  transit  at  Houston 

98.58  Convoy3  started  a  4.6  hour  delay  in  transit  at  Houston 
100.22  Convoy5  started  a  2.8  hour  delay  in  transit  at  Houston 

101.99  Convoyl  started  a  5.0  hour  delay  in  transit  at  Houston 
102.36  Convoy2  started  a  4.4  hour  delay  in  transit  at  Houston 
102.52  Houston's  road  facility  repaired. 

102.99  ConvoyS  leaving  Houston  and  moving  to  Abilenel91.0  miles  away. 

.  103.23  Convoy3  leaving  Houston  and  moving  to  Abilenel91.0  miles  away. 

106.73  Convoy2  leaving  Houston  and  moving  to  Abilenel91.0  miles  away. 
107.01  Convoyl  leaving  Houston  and  moving  to  Abilenel91.0  miles  away. 
122.09  Convoy5  arrived  at  Abilene 

122.09  Convoy5  started  a  4.5  hour  delay  in  transit  at  Abilene 

122.33  Convoy3  arrived  at  Abilene 

122.33  Convoy3  started  a  4.0  hour  delay  in  transit  at  Abilene 
125.83  Convoy2  arrived  at  Abilene 

125.83  Convoy2  started  a  3.5  hour  delay  in  transit  at  Abilene 

126.12  Convoyl  arrived  at  Abilene 

126.12  Convoyl  started  a  3.5  hour  delay  in  transit  at  Abilene 

126.30  Convoy3  leaving  Abilene  and  moving  to  Sweetwater  40.0  miles  away. 

126.58  Convoy5  leaving  Abilene  and  moving  to  Sweetwater  40.0  miles  away. 
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129.35  Convoy2  leaving  Abilene  and  moving  to  Sweetwater  40.0  miles  away. 

129.59  Convoy  1  leaving  Abilene  and  moving  to  Sweetwater  40.0  miles  away. 
130.30  Convoy3  arrived  at  Sweetwater 

130.30  Convoy3  started  a  1.3  hour  delay  in  transit  at  Sweetwater 
130.58  Convoy5  arrived  at  Sweetwater 

130.58  Convoy5  started  a  3.8  hour  delay  in  transit  at  Sweetwater 
131.61  Convoy3  leaving  Sweetwater  and  moving  to  Lubbock  51.0  miles 

away. 

133.35  Convoy2  arrived  at  Sweetwater 

133.35  Convoy2  started  a  2.8  hour  delay  in  transit  at  Sweetwater 

133.59  Convoyl  arrived  at  Sweetwater 

133.59  Convoyl  started  a  4.5  hour  delay  in  transit  at  Sweetwater 

134.39  Convoy5  leaving  Sweetwater  and  moving  to  Lubbock  51.0  miles 
away. 

135.01  Convoy3  arrived  at  Lubbock 

135.01  Convoy3  started  a  3.4  hour  delay  in  transit  at  Lubbock 

136.10  Convoy2  leaving  Sweetwater  and  moving  to  Lubbock  51.0  miles 
away. 

137.79  Convoy5  arrived  at  Lubbock 

137.79  Convoy5  started  a  3.6  hour  delay  in  transit  at  Lubbock 

138.13  Convoyl  leaving  Sweetwater  and  moving  to  Lubbock  51.0  miles 
away. 

138.39  Convoy3  leaving  Lubbock  and  moving  to  Abernathy  51.0  miles  away. 
139.50  Convoy2  arrived  at  Lubbock 

139.50  Convoy2  started  a  4.5  hour  delay  in  transit  at  Lubbock 

141.39  Convoy5  leaving  Lubbock  and  moving  to  Abernathy  51.0  miles  away. 
141.53  Convoyl  arrived  at  Lubbock 

141.53  Convoyl  started  a  5.1  hour  delay  in  transit  at  Lubbock 

141.79  Convoy3  arrived  at  Abernathy 

141.79  Convoy3  started  a  3.6  hour  delay  in  transit  at  Abernathy 

144.00  Convoy2  leaving  Lubbock  and  moving  to  Abernathy  5 1.0  miles  away. 

144.79  Convoy5  arrived  at  Abernathy 

144.79  Convoy5  started  a  2.7  hour  delay  in  transit  at  Abernathy 

145.44  Convoy3  leaving  Abernathy  and  moving  to  Plainview  51.0  miles 
away. 

146.63  Convoyl  leaving  Lubbock  and  moving  to  Abernathy  51.0  miles  away. 

147.40  Convoy2  arrived  at  Abernathy 

147.40  Convoy2  started  a  2.9  hour  delay  in  transit  at  Abernathy 
147.47  Convoy5  leaving  Abernathy  and  moving  to  Plainview  51.0  miles 
away. 

148.84  Convoy3  arrived  at  Plainview 
150.02  Convoyl  arrived  at  Abernathy 

150.02  Convoyl  started  a  4.7  hour  delay  in  transit  at  Abernathy 
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150.35  Convoy2  leaving  Abernathy  and  moving  to  Plainview  51.0  miles 
away. 

150.87  Convoy5  arrived  at  Plainview 
153.75  Convoy2  arrived  at  Plainview 

154.77  Convoy  1  leaving  Abernathy  and  moving  to  Plainview  5 1.0  miles 
away. 

158.17  Convoyl  arrived  at  Plainview 
Closing  the  War  Diary 

Notice  that  the  effects  of  interdiction  are  seen  by  the  convoys  backing  up 
in  Houston  between  14.77  and  102.52  hours.  The  materiel  that  is  stuck  in 
Houston  can  be  identified  using  the  Supply  Diary. 

2.  SUPPLY  DIARY 

Although  not  found  in  this  example,  many  Supply  Diaries  will  list 
“Manna”  as  having  filled  an  order  for  the  FLB  at  Houston.  This  indicates 
materiel  that  has  flowed  into  theater. 

Supply  Diary 

19.10  IDiv  consumed  6262  of  MoGas.  Onhand:  5738. 

19.10  Houston  rcvd  req  for  6262  MoGas 

19.10  Houston  has  filled  an  order  for  6262  of  MoGas 

19.10  Convoyl  formed  for  IDiv  using  8  truck 
24.00  IDiv  consumed  39974  of  CRAT.  Onhand:  60026. 

24.00  Abilene  rcvd  req  for  39974  CRAT 

24.00  Abilene  must  backorder  29974  CRAT 

24.00  Abilene  has  filled  an  order  for  10000  of  CRAT 

24.00  IDiv  received  10000  CRAT  from  Abilene.  Now  onhand:  70026. 

24.00  Houston  rcvd  req  for  29974  CRAT 
24.00  Houston  has  filled  an  order  for  29974  of  CRAT 
24.00  Convoy2  formed  for  IDiv  using  29  truck 

44.27  Abilene  rcvd  req  for  24806  CRAT 

44.27  Abilene  must  backorder  24806  CRAT 

44.27  Houston  rcvd  req  for  24806  CRAT 

44.27  Houston  has  filled  an  order  for  24806  of  CRAT 

44.27  Convoy3  formed  for  IDiv  using  24  truck 

46.63  IDiv  consumed  1191  of  MoGas.  Onhand:  4547. 

46.63  Abilene  rcvd  req  for  1191  MoGas 

46.63  Abilene  has  filled  an  order  for  1191  of  MoGas 

46.63  Convoy4  formed  for  IDiv  using  1  truck 
48.00  IDiv  consumed  41507  of  CRAT.  Onhand:  28519. 

48.00  Abilene  rcvd  req  for  41507  CRAT 
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48.00  Abilene  must  backorder  41507  CRAT 

48.00  Houston  rcvd  req  for  41507  CRAT 

48.00  Houston  has  filled  an  order  for  41507  of  CRAT 

48.00  Convoy5  formed  for  IDiv  using  41  truck 

49.13  IDiv  received  1191  MoGas  from  Convoy4.  Now  onhand:  5738. 

51.67  IDiv  consumed  1639  of  MoGas.  Onhand:  4099. 

51.67  Abilene  rcvd  req  for  1639  MoGas 

51.67  Abilene  has  filled  an  order  for  1639  of  MoGas 

51.67  Convoy6  formed  for  IDiv  using  2  truck 

62.07  IDiv  received  1639  MoGas  from  Convoy6.  Now  onhand:  5738. 

64.62  IDiv  consumed  1695  of  MoGas.  Onhand:  4043. 

64.62  Lubbock  rcvd  req  for  1695  MoGas 

64.62  Lubbock  has  filled  an  order  for  1695  of  MoGas 

64.62  Convoy 7  formed  for  IDiv  using  2  truck 

67.02  IDiv  received  1695  MoGas  from  Convoy7.  Now  onhand:  5738. 

69.57  IDiv  consumed  1656  of  MoGas.  Onhand:  4082. 

69.57  Lubbock  rcvd  req  for  1656  MoGas 

69.57  Lubbock  has  filled  an  order  for  1656  of  MoGas 

69.57  Convoy8  formed  for  IDiv  using  2  truck 
Closing  Supply  Diary 
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APPENDIX  D.  THE  DATABASES 

This  Appendix  contains  all  of  the  various  databases  used  by  the  code 
along  with  explanatory  notes.  The  databases  are  printed  in  New  Courier,  a  fixed 
pitch  font,  to  show  precisely  how  they  are  listed.  The  code  has  a  certain 
resiliency  about  how  sloppy  the  data  may  be  listed,  but  not  much. 
FileManager.FileTracker.ParseChar  shows  the  different  delimiters  it  can 
recognize:  tab  spaces,  commas,  colons,  and  semicolons.  Periods  may  not  be 
used  since  they  denote  real  numbers. 

In  general,  the  code  expects  to  find  data  immediately  following  a  [Field 
Name]  listing  and  will  read  the  data  until  it  finds  the  next  [Field  Name].  A  few 
other  fields  will  use  just  the  field  name  without  brackets  and  use  “end.”  to 
denote  the  end  of  the  field.  Since  different  processes  in  the  program  may  need 
different  fields  from  different  files,  or  multiple  fields  from  one  single  file,  the 
fields  themselves  are  not  generally  in  any  sequential  order.  When  a  field  is 
needed,  a  FileTracker  opens  the  appropriate  file  and  searches  until  it  finds  the 
data  field  heading  it  seeks.  However,  the  program  does  expect  the  listings 
within  a  field  to  be  in  orders  listed  here. 

Although  the  tabulated  data  are  separated  by  tab  spaces,  the  program 
recognizes  spaces,  commas,  semicolons,  tab  spaces,  and  period  delimiters.  The 
coding  for  the  delimiter  recognition  is  in  FileManger.FileTracker.ParseChar. 

The  databases  give  the  program  a  great  deal  of  flexibility  by  allowing 
different  scenarios  to  be  rim  by  changing  a  few  lines  in  the  appropriate  database. 
Recompilation  of  the  program  is  therefore  unnecessary. 


A.  FileManager  DATABASES 

The  FileManager  object  FileTracker  uses  two  files  constantly: 
FMScratchpad  and  TypelD. 

1 .  FILE  NAME  FMScratchpad 

A  FileManger.FileTracker  object  depends  upon  FMScratchpad  to  operate. 
FMScratchpad  is  hardwired  into  a  FileTracker’s  RootSource  field  by  Objlnit  and 
lists  all  of  the  file  paths  used  in  the  program. 

For  example,  suppose  a  method  needs  to  change  a  TerrainType  to  a 
string.  Since  the  FileTracker  is  working  with  a  user  enumerated  type,  it  opens 
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FMScratchpad,  looks  for  “userTypes”,  and  finds  that  they  are  listed  in 
“inputFiles/TypelD”. 


FileManager  Scratchpad 

Input  directory:  InputFiles/ 

Output  directory:  OutputFiles/ 

Data  Input  files 
Agressor:  InputFiles/Agressor 
Defender:  InputFiles/Defender 
Map:  InputFiles/NetworkData 
WeaponsData :  InputFiles/WeaponsData 
Movement:  InputFiles/ForceData 
UserTypes:  InputFiles/TypelD 

LogPlanFactors :  InputFiles/LogisticsPlanningFactors 
DepotList:  InputFiles/DepotList  ' 

IMTransport:  InputFiles/IMTransportAssignments 

Ref ereelnitialization:  InputFile/RefereeStandingOrders 

Data  output  files: 

MapDump:  OutputFiles/MapStructure 
LPFODump:  OutputFiles /LPFODump 

WarDiary:  OutputFiles/WarDiary 
SupplyDiary:  OutputFiles/SplyDiary 

2.  FILE  NAME  TypelD 


TypelD  lists  all  of  the  user  enumerated  types  as  they  are  found  in  the 
various  definition  modules.  It  is  absolutely  essential  that  these  listings  match 
exactly  in  spelling  and  ordinal  the  definition  listing  or  errors  will  result. 
Comma  delimiters  are  also  required,  and  the  line  headers  must  match  the 
spelling  of  the  enumerated  type. 


TypelD 

rainT ype :  plain,  hilly,  mountainous,  marshy,  desert 
WeaponType:  MBT,  INF,  CAS,  Arty 

SplyClassType :  subsistence,  super,  POL,  ammo,  major 
ModeType:  air,  rail,  road,  sea,  JLOTS,  IPDS 

MovingOb j Type :  truck,  train,  C130,  ship,  ELCAS,  pipeline  opforce, 
combat,  engineer 


B-  MovingObj  TERRAIN  MOVEMENT  DATABASE 


Force  Data 

Terrain  Movement  Rates 


Plain 

hilly 

mountainous 

combat : 

20 

.  10 

5 

opforce: 

20 

15 

1 

engineer: 

15 

12 

5 

truck: 

15 

10 

5 

C130 : 

END  TERRAIN 

250 

250 

250 

marshy  desert 

1  2 

3  8 

1  2 

1  2 

250  250 
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C.  FORCE  AND  DEPOT  SYSTEM  FILES 


FileTracker  uses  three  files.  Aggressor,  Defender,  and  DepotList,  to  tell  the 
model  run  what  files  to  use  for  Blue  forces.  Red  forces,  and  Depots. 

1.  MovingObjType  FILES 

Aggressor  and  Defender  tell  the  RefereeObj  what  files  to  use  for  Blue  and 
Red  Force  objects.  A  template  is  shown  below.  Each  unit  in  the  Force  object 
has  a  fine  fisting.  The  file  name  should  be  the  name  of  the  unit. 

“FileName”  MovingObjType 

2.  DepotList  FILES 

The  DepotList  tells  the  RefereeObj  which  cities  will  have  a  Depot. 
Simply,  the  file  fists  each  site  that  has  a  depot  on  its  own  fine.  The  fisting  must 
match  the  spelling  entered  in  the  network  database,  and  the  very  first  entry  is 
assumed  to  be  the  forward  logistics  base. 


D.  UnitType  DATABASES 

UnitType  Objects  use  the  format  shown  for  the  Blue  and  Red  units.  Both 
types  need  the  Unit,  Weapons,  and  Mission  fields,  although  Red  units  cannot 
use  the  LiftMOType  and  LiftPerPerson  entries  under  Unit  Data.  Only  the  Blue 
units  need  the  Unit  Load  Out  field.  The  Unit  Load  Out  shows  what  a 
Logistics l.LoadListObj  looks  like. 

As  noted  in  the  Weapons  Data  field,  the  unit’s  weapons  systems  are 
columnar  and  the  opposition  systems  are  by  row.  While  backwards  from  most 
listings  of  this  type,  this  approach  simplified  data  entry  in  this  case. 

Originally,  military  (meter)  grid  system  was  intended  for  use.  However, 
since  most  theaters  cannot  fit  onto  a  single  map  and  the  program  cannot  process 
alphanumeric  grid  designators,  the  unit  of  measure  changed  to  the  mile.  The 
grids  fisted,  then,  are  based  on  Cartesian  coordinate  system  in  the  first  quadrant 
only. 


1.  BLUE  FORCES 

File  name:  IDiv 

[Unit  Data] 

Name : IDiv 
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Number:  20000 
Location:  Houston 
LiftPerPerson:  0. 04 
Li f tMOType :  truck 
Grids: 08911235 

[Weapons  Data] 

Note:  Columns  represent  this  unit's  data.  Rows  are  opposition  data 

Force  Breakpoint:  4 


Weapons  Types: 

MBT 

INF 

CAS 

Arty 

Weapons  Load: 

256 

17000 

72 

267 

Weapons  Breakpoint : 

0.75 

0.8 

0.9 

0.8 

Psi :  xx 

MBT 

0.5 

0.25 

0.25 

0.25 

INF 

0.25 

0.75 

0.25 

0.25 

CAS 

0.0 

0.0 

0.25 

0.25 

Arty 

0.25 

0.0 

0.25 

0.25 

Ammo  Type :  xx 

MBT 

HE-1 

LAAW 

HELLFIR 

HE-2 

INF 

PD-1 

NATO 

BOMB 

PD-2 

CAS 

None 

None 

AIM9 

PD-2 

Arty 

PD-1 

None 

HELLFIR 

PD-2 

[Unit  Load  Out] 

ULO : 

subs 

super 

POL 

Ammo 

Major 

Commodity: 

CRAT 

NoFill 

JP5 

LAAW 

truck 

Onhand: 

100000 

50000 

1000 

800 

Cap: 

100000 

700 

1000 

800 

Reorder: 

0.9 

0.75 

0.9 

0.9 

Commodity: 

NoFill 

NoFill 

Mo  Gas 

BOMB 

MBT 

Onhand: 

12000 

6000 

256 

Cap: 

12000 

6000 

256 

Reorder: 

0.6 

0.9 

1.0 

Commodity: 

NoFill 

NoFill 

NoFill 

HELLFIR 

INF 

Onhand : 

400 

17000 

Cap: 

400 

17000 

Reorder: 

0.9 

1.0 

Commodity: 

NoFill 

NoFill 

NoFill 

AIM9 

CAS 

Onhand : 

50 

72 

Cap : 

50 

72 

Reorder: 

0.9 

1.0 

Commodity: 

NoFill 

NoFill 

NoFill 

NATO 

Arty 

Onhand: 

2000000 

267 

Cap: 

2000000 

267 

Reorder: 

0.9 

1.0 

Commodity: 

NoFill 

NoFill 

NoFill 

HE-1 

NoFill 

Onhand: 

400 

Cap: 

400 

Reorder: 

0.9 
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Commodity: 

NoFill  NoFill  NoFill  PD-1 

NoFill 

Onhand : 

50 

Cap: 

50 

Reorder: 

0.9 

Commodity: 
Onhand : 

Cap : 

Reorder: 


NoFill  NoFill  NoFill  HE-2  NoFill 

2000000 

2000000 

0.9 


Commodity: 
Onhand : 
Cap: 

Reorder: 


NoFill  NoFill  NoFill  PD-2  NoFill 

400 

400 

0.9 


Mission: 

Houston,  US-36 
Abilene,  1-20 
Sweetwater,  US-86 
Lubbock,  1-25 
Abernathy,  1-25 
Plainview,  STOP 

end. 


2.  RED  FORGES 

File  name:  789thMech 

Name:  789thMech 

Number:  15000 
Location:  Plainview 

Grids:  00050035 

[Weapons  Data] 

Note:  Columns  represent  this  unit's  data.  Rows  are  opposition  data 


Force  Breakpoint:  4 


Weapons 

Types : 

MBT 

INF 

CAS 

Arty 

Weapons 

Load: 

200 

15000 

50 

267 

Weapons 

Breakpoint : 

0.75 

0.8 

0.9 

0.8 

Psi :  xx 

MBT 

0.5 

0.25 

0.25 

0.25 

INF 

0.25 

0.75 

0.25 

0.25 

CAS 

0.0 

0.0 

0.25 

0.25 

Arty 

0.25 

0.0 

0.25 

0.25 

Mission: 
Plainview,  1-25 
Abernathy,  1-25 
Lubbock,  US-86 
Sweetwater,  1-20 
Abilene,  US-36 
Houston,  STOP 
end. 
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3.  COMBAT  MODEL  INFORMATION 


These  databases  show  the  data  used  in  the  combat  model  section, 
the  listing  for  the  UnitTypes,  opposition  data  is  columnar. 

WeaponsData 

{NOTE:  Subheadings  PSSK  and  FIRETYPE  need  the  "xx"'  s 

after  or  program  crashes  in  FindField,  Isloate 
PSSK  and  FIRETYPE  are  read  by  row  against  opposer  column} 


[Red  Data] 

WeaponType  Rounds/hr  Footprint- sqft  Crew  Size 


MBT 

80 

3000 

5 

INF 

100 

400 

1 

CAS 

75 

1000000 

1 

ARTY 

120 

10000 

8 

Pssk:  xx 

MBT 

INF 

CAS 

Arty 

MBT:  0.0023 

0.0001 

0.0001 

0.0023 

INF:  0.0001 

0.0023 

0.0001 

0.0001 

CAS:  0.0030 

0.0015 

0.0010 

0.0045 

Arty:  0.0034 

0.0024 

0.0001 

0.0901 

FireType:  xx 

MBT 

INF 

CAS 

Arty 

MBT :  Aimed 

Aimed 

Aimed 

Aimed 

INF :  Aimed 

Aimed 

Aimed 

Aimed 

CAS :  Aimed 

Aimed 

Aimed 

Aimed 

Arty:  Aimed 

Aimed 

Aimed 

Aimed 

[Blue  Data] 

WeaponType  Rounds/hr 

Footprint-sqft 

Crew  Size 

MBT 

80 

3100 

5 

INF 

120 

415 

1 

CAS 

67 

1000234 

1 

Arty 

89 

10012 

8 

Pssk:  xx 

MBT 

INF 

CAS 

Arty 

MBT:  0.0023 

0.0001 

0.0001 

0.0023 

INF:  0.0001 

0.0023 

0.0001 

0.0001 

CAS:  0.0030 

0.0015 

0.0010 

0.0045 

Arty:  0.0034 

0.0024 

0.0001 

0.0901 

FireType:  xx 

MBT 

INF 

CAS 

Arty 

MBT :  Aimed 

Aimed 

Aimed 

Aimed 

INF:  Aimed 

Aimed 

Aimed 

Aimed 

CAS :  Area 

Area 

Aimed 

Aimed 

Arty:  Area 

Area 

Area 

Area 

Unlike 
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E.  DEPOT  DATABASES 


The  DepotList  tells  the  Referee  which  sites  will  have  a  depot  and  what 
the  name  of  the  file  is  for  that  depot:  depot  file  names  are  the  site  names  with 
“Depot”.  The  filename  for  the  forward  logistics  base  at  Houston  is 
“HoustonDepot”.  Although  intermediate  depots  need  not  have  a  listing  for 
every  item  used  in  the  theater,  the  forward  logistics  base  must,  even  if  the  item 
is  not  carried  by  the  FLB.  If  the  FLB  receives  a  request  for  an  item  it  does  not 
list,  the  program  will  halt  and  notify  the  user.  Note  that  the  supply  listing  is  a 
LoadListObj. 


The  Depot  at  Houston. 


ULO: 

sub 

super 

POL 

ammo 

major 

Commodity: 

MRE 

Stuff 

MoGas 

NATO 

truck 

Onhand : 

1000 

23 

700000 

8000000 

1000 

Cap: 

2000 

23 

700000 

8000000 

1000. 

Reorder: 

0.1 

0.1 

0.1 

0.7 

0.1 

Commodity: 

CRAT 

Mores 

JP5 

LAAW 

C130 

Onhand: 

500000 

234 

50000 

100 

3 

Cap: 

500000 

500 

50000 

700 

3 

Reorder: 

0.1 

0.1 

0.1 

0.1 

0.1 

Commodity: 

NoFill 

Bridge 

NoFill 

BOMB 

MBT 

Onhand : 

3 

10 

50 

Cap: 

3 

6000 

50 

Reorder: 

0.0 

0.1 

1.0 

Commodity: 

NoFill  . 

bldg 

NoFill 

HELLFIR 

INF 

Onhand : 

10 

400 

1000 

Cap: 

20 

400 

1000 

Reorder: 

0.5 

0.1 

1.0 

Commodity: 

NoFill 

NoFill 

NoFill 

AIM9 

CAS 

Onhand: 

45 

15 

Cap : 

50 

15 

Reorder: 

0.1 

1.0 

Commodity: 

NoFill 

NoFill 

NoFill 

LGB 

Arty 

Onhand: 

600 

4 

Cap : 

700 

10 

Reorder: 

0.1 

1.0 

Commodity: 

NoFill 

NoFill 

NoFill 

HE-1 

NoFill 

Onhand: 

400 

Cap: 

400 

Reorder: 

0.9 

Commodity: 

NoFill 

NoFill 

NoFill 

PD-1 

NoFill 

Onhand : 

50 

Cap: 

50 

Reorder: 

0.9 

77 


Commodity: 

NoFill  NoFill 

NoFill 

HE-2 

Onhand : 

2000000 

Cap: 

2000000 

Reorder: 

0.9 

Commodity: 

NoFill  NoFill 

NoFill 

PD-2 

Onhand : 

400 

Cap: 

400 

Reorder: 

0.9 

F.  MAP  STRUCTURE 

NoFill 


NoFill 


The  file  path  for  the  network  data  is  given  in  FMScratchpad.  Each  listing 
in  the  file  is  a  terminal  with  its  forward  star  of  arcs.  MapStructure.CreateMap 
uses  the  GeoLoc  field  to  attach  the  terminal  to  a  site.  If  a  site  with  a  terminal’s 
GeoLoc  field  does  not  exist,  one  will  be  created.  A  site  may  have  a  single 
terminal,  such  as  a  bridge  or  tunnel  listing,  or  many,  as  a  city  might.  Since  each 
terminal  is  read  individually,  no  specific  order  is  necessary.  On  the  other  hand, 
it  is  essential  that  each  site’s  spelling  is  used  consistently  throughout  since  the 
name  is  used  as  a  unique  identifier.  A  misspelled  name  can  cause  a  site  to  be 
created  with  unintended  consequences  when  arcs  fail  to  go  where  they  are 
imagined.  Finally,  each  arc  is  directed.  If  a  two  way  rail  arc  exists  between 
Abilene  and  Houston,  it  must  be  listed  as  an  arc  from  Abilene  to  Houston,  and 
as  an  arc  from  Houston  to  Abilene. 


NetworkData 

GeoLoc:  Abernathy 

Grids:  00040030 

Desc:  1-25 

Mode :  road 

Cap:  1400  trucks/day 

Star: 

Lubbock  plain  1400  trucks/day 
Plainview  plain  1400  trucks/day 
end, 

GeoLoc:  Lubbock 

Grids:  00050025 

Desc:  Santa  Fe  yard 

Mode:  rail 

Cap:  350  cars/day 

Star: 

Abernathy  plain  350  cars/day 
Sweetwater  plain  350  cars/day 
Abilene  plain  350  cars/day 

end. 

GeoLoc:  Houston 

Grids:  00120001 

Desc:  Rail  Yard 

Mode:  rail 

Cap:  700  cars/day 

Star: 
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Sweetwater  hilly  200  cars/day 
Abilene  hilly  350  cars/day 
end. 

GeoLoc:  Lubbock 

Grids:  00050025 

Desc:  US-86 

Mode :  road 

Cap:  1000  trucks/day 

Star: 

Sweetwater  plain  1000  trucks/day 
end. 

GeoLoc:  Sweetwater 

Grids :  00060020 

Desc:  US-86 

Mode :  road 

Cap:  1000  trucks/day 

Star: 

Lubbock  plain  1000  trucks/day 
end. 

GeoLoc:  Sweetwater 

Grids:  00060020 

Desc:  1-20 

Mode :  road 

Cap:  1800  trucks/day 

Star: 

Abilene  hilly  1800  trucks/day 

end. 

GeoLoc:  Abilene 

Grids:  00100020 

Desc:  US-36 

Mode :  road 

Cap:  400  trucks/day 

Star: 

Houston  hilly  400  trucks/day 
end. 

GeoLoc:  Abilene 

Grids:  00100020 

Desc:  1-20 

Mode :  road 

Cap:  1800  trucks/day 

Star: 

Sweetwater  hilly  1800  trucks/day 
end . 

GeoLoc:  Houston 

Grids:  00120001 

Desc:  US-36 

Mode :  road 

Cap:  400  trucks/day 

Star: 

Abilene  hilly  1800  trucks/day 
end. 

GeoLoc:  Houston 
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Grids:  00120001 
D esc:  Port  of  Houston 

Mode :  sea 

Cap:  700  containers/day 

Star: 

SuperSeaNode  plain  0  ships/day 
end . 

GeoLoc:  Sweetwater 
Grids:  00060020 
Desc:  Rail  yard 

Mode:  rail 

Cap:  350  cars/day 

Star: 

Lubbock  plain  350  cars/day 

Abilene  hilly  350  cars/day 

Houston  hilly  200  cars/day 
end. 

GeoLoc:  Abernathy 
Grids:  00040030 
Desc:  Rail  yard 

Mode:  rail 

Cap:  300  cars/day 

Star: 

Lubbock  plain  300  cars/day 

Plainview  plain  300  cars/day 
end. 

GeoLoc:  Plainview 

Grids:  00050035 

Desc:  1-25 

Mode:  road 

Cap:  1500  trucks/day 

Star: 

Abernathy  plain  1500  trucks/day 
end. 

GeoLoc:  Plainview 
Grids:  00050035 
Desc:  siding 

Mode:  rail 

Cap:  300  cars/day 

Star : 

Abernathy  plain  1500  trucks/day 
end . 

GeoLoc:  Lubbock 

Grids:  00050025 

Desc:  1-25 

Mode :  road 

Cap:  1400  trucks/day 

Star: 

Abernathy  plain  1500  trucks/day 
end. 

GeoLoc:  Abilene 
Grids:  00040030 
Desc:  Rail  Yard 
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Mode:  rail 

Cap:  350  cars/day 

Star: 

Lubbock  plain  350  cars/day 

Sweetwater  hilly  350  cars/day 

Houston  hilly  350  cars/day 

end. 

G.  LOGISTICS  PLANNING  FACTORS 

The  logistics  planning  factors  are  shown  below.  Each  planning  factor 
must  be  listed  under  its  SplyClassType.  If  the  program  cannot  find  the  planning 
factor  it  seeks,  it  notifies  the  user  and  halts.  Some  items  may  be  both  a 
commodity  and  a  user.  For  instance,  trucks  are  used  by  MovingObjTypes 
combat  and  engineer,  but  use  MoGas  themselves. 

Logistics  Planning  Factors. 

[subsistence] 

NounName :  MRE 
User:  combat 
HighUseage:  3 
MedUseage:  2 
LowUseage: 1 
Weight :1 
CUFT : 0 . 2 

NounName :  CRAT 
User:  combat 
HighUseage:  3 
MedUseage : 2 
LowUseage :1 
Weight : 1 
CUFT : 0 . 5 

NounName:  CRAT 
User:  engineer 
HighUseage:  3 
MedUseage:  2 
LowUseage:  1 
Weight:  1 
CUFT : 0 . 5 

NounName:  Water 
User:  combat 
HighUseage:  25 
MedUseage:  15 
LowUseage:  5 
Weight:  8 
CUFT:  0.66 
[super] 

NounName:  Stuff 
User:  combat 
HighUseage:  5 
MedUseage:  4 
LowUseage: 1 
Weight : 23 
CUFT : 1 
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NounName :  Bridge 
User:  engineer 
HighUseage:  1 
MedUseage:  1 
LowUseage:  1 
Weight  10000 
CUFT:  500 

NounName :  bldg 
User:  engineer 
HighUseage  2 
MedUseage  1.5 
LowUseage  1 
Weight  2000 
CUFT:  10 

NounName:  Mores 
User:  combat 
HighUseage: 5 
MedUseage: 3 
LowUseage: 2 
Weight: 2 
CUFT :  2 

[POL] 

NounName:  MoGas 
User:  combat 
HighUseage:  0.05 
MedUseage:.  0.04 
LowUseage:  0.03 
Weight:  7 
CUFT:  0.66 

NounName:  MoGas 
User:  truck 
HighUseage:  0.05 
MedUseage:  0.04 

LowUseage:  0.033 
Weight:  7 
CUFT:  0.66 

NounName:  JP5 
User:  C130 
HighUseage:  400 
MedUseage:  350 

LowUseage:  200 

Weight:  7 
CUFT: 0.66 

[ammo] 

NounName:  Dragon 
User:  combat 
HighUseage:  3 
MedUseage: 2 
LowUseage : 1 
Weight: 100 
CUFT: 10 


N ounN ame :  LAAW 
User:-  combat 
HighUseage:  3 
MedUs eager  2 
LowUseage: 1 
Weight:  100 
CUFT:  10 

N  ounN  ame :  BOMB 
User:  combat 
HighUseage:  8 
MedUs eage:  6 
LowUseage:  4 
Weight:  500 
CUFT:  12 

NounName:  HELLFIR 
User:  combat 
HighUseage:  8 
MedUs eage :  6 
LowUseage :  4 
Weight:  500 
CUFT:  12 

NounName:  AIM9 
User:  combat 
HighUseage:  1 
MedUseage:  1 
LowUseage:  1 
Weight:  500 
CUFT:  12 

N  ounN  ame :  NATO 
User:  combat 

HighUseage:  1 
MedUseage :  1 
LowUseage:  1 
Weight:  0.04 
CUFT:  0.001 

NounName:  HE-1 

User:  combat 

HighUseage:  1 
MedUseage:  1 
LowUseage:  1 
Weight:  35 
CUFT :  1 

NounName:  PD-1 

User:  combat 

HighUseage:  1 
MedUseage:  1 
LowUseage:  1 
Weight:  35 
CUFT :  1 

NounName:  HE-2 

User:  combat 

HighUseage:  1 


MedUseage:  1 
LowUseage:  1 
Weight:  35 
CUFT :  1 

NounName :  PD-2 

User:  combat 

HighUseage:  1 
MedUseage:  1 
LowUseage:  1 
Weight :  35 
CUFT :  1 

[major] 

NounName:  truck 

User:  truck 

HighUseage:  1 
MedUseage:  1 
LowUseage:  1 
Weight:  5000 
CUFT:  500 

NounName :  MBT 
User:  combat 

HighUseage:  1 
MedUseage:  1 
LowUseage:  1 
Weight:  40000 
CUFT:  4000 

NounName :  INF 

User:  combat 

HighUseage:  1 
MedUseage:  1 
LowUseage:  1 
Weight:  200 
CUFT:  24 

NounName:  CAS 

User:  combat 

HighUseage:  1 
MedUseage:  1 
LowUseage:  1 
Weight:  1 
CUFT :  1 

NounName :  Arty 

User:  combat 

HighUseage:  1 
MedUseage:  1 
LowUseage:  1 
Weight:  4000 

CUFT:  1000 
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